I tried finding this on the internet but could not find anything regarding it. There are ways to skip errors in the Distribution agent but nothing with respect to skipping Errors while applying Snapshot.
My Question: I have a Multi Publisher Single Subscriber setup. While setting up replication, the Snapshot of the first Publisher is successfully delivered to the subscriber. The snapshot of the consecutive Publishers is successfully generated but fails while applying it to the subscriber. The failure is due to Primary Key violation. Is there a way to skip errors while the snapshot is being applied on the subscriber?
Environment:
Publisher: Microsoft SQL Server 2008 R2 (SP2) - (X64)
Distributor: Microsoft SQL Server 2014 (SP2) (KB3171021) - (X64)
Subscriber: Microsoft SQL Server 2008 R2 (SP3-OD) (KB3144114) - (X64)
I have tried identifying the tables and records which are causing this issue but there are over 100 such tables having hundreds of records each.
Since replication is a client requirement, I don't have much control over the schema and the data in it.
It sounds like something in your setup is incorrect, which is leading to multiple tables from different publishers trying to insert rows into the same subscriber table, hence the duplicate key records.
If the different publishers all have the same copy of the same table, you only want to publish it from one of them.
If the different publishers all have different copies of the same table, you want them to each have their own subscriber tables.
Otherwise you'll end up missing a lot of rows in your subscriber (because different publishers are using the same key for rows that are actually different) or hitting weird replication errors. Just skipping the errors would result in having incorrect data-- and I'm guessing that's one of the client requirements as well.
One option that I have used in the past to simplify replication topography and management:
One subscriber database per publication
Never grant write access to users to these databases
Grant read access via another database which uses synonyms or views
This can make management simpler down the road as well. If you need to re-initialize a single database, you have the option to restore it from backup and generally more flexibility than if your subscribers are all sharing the same database.
Just for completeness, I should probably point you to the Books Online entry from Skipping Errors in Transactional Replication. But to be clear, I think this would be a mistake, as you'd end up with incorrect data -- and that's probably not what anyone wants.
Related
we have a Database Replication set up where we Replicate all Tables of a Database to multiple Production Servers.
There are also Views, Stored Procedures, Functions, etc. in the Database which are manually deployed to the Replicates through TSQL Scripts.
Now if for example a new table is added to the Publication, we have to reinitialize all Subscriptions by creating a new snapshot and let it deliver through the Distributor (which is on the same server as the Publication). The Headache starts when the Distribution Agent wants to drop the Table to recreate it afterwards, some Tables are been referenced by views, which have also been referenced by another objects. the Distributor cannot (or will not) drop the objects and runs into an error like Cannot DROP TABLE 'dbo.table' because it is being referenced by object 'thisisafunctionorview'.
In the past we also had the Views, Functions and StoredProcedures in the Publication but that caused even more Pain (Reinitialisation had to be done after each minor change on procedures, etc.), also then the reference problems where really frustrating.
To resolve this issue we have to drop all functions and views (in total about 200 Objects) and recreate them after the snapshot had been delivered.
Does someone have an idea how we could modify the concept of this replication that we could change objects and not having to set a massive downtime (about 2h for 6 Replicates) to fix the mess because of the references?
To complete the Information:
We use MS SQL Server 2008 R2 on all the instances (with Enterprise and Standard Editions). Upgrade to SQL Server 2014 is planned later this year for the Publisher and some of the Subscribers.
Only the Publication demands writing access.
Updates to the schema of the Database are deployed frequently (about twice a month) usually there are only changes in Procedures but sometimes there were tables added / modified, thats where our replication concept seems to falls apart.
Any suggestions are welcome
Thanks in advance!
Sincerely
David
It sounds strange to me because I have a lot of stored procedures in replication and there is no problems with SP changes. ALTER PROCEDURE can be propagated on subscriptions. Also I see no problems with subscriptions re-initialization because of objects dependencies. I can remember such problems in merge replication though, and there is SP to re-arrange objects. In most cases SQL Server handles dependencies well. Second note, you can add\remove articles to transactional replication without re-initialization.
I think if you re-create replication on test environment and play with it a little bit, you'll find a way how to replicate schema changes and don't do re-initialization too often. It is possible but requires some efforts.
I have transactional replication with updatable subscriptions going between a few SQL 2008 R2 servers (publisher is Enterprise, subscribers are Express).
I need to add another subscriber, and come to discover that my database has outgrown the 10GB limit for Express. My current subscribers are under the 10GB limit, however the publishing database is 13GB.
So I delete some large unused columns and data from the largest tables, run dbcc cleantable, run update statistics on them, the tables go down in size a bit and I thought I was good to go!
However, the publishing database is still a good 11.5GB while the subscribers all went down to 8GB.
I compare table sizes between the publishers and subscribers and the few largest tables that I had deleted data from are larger in the publishing database than the subscribing databases - by a couple gigs.
I compare table structures and use RedGate's Data Compare - the tables are identical between the publisher and subscribers so I am at a loss. I don't know what is cause the discrepancy let alone how to resolve it so I can add another subscriber (without having to buy SQL Standard licenses for the subscriber). I have a feeling it has to do with being the publisher and it's row-count has grown significantly within the last year.
As a side note - I do also have a couple SQL Standard 2008 licenses, however they're 2008, not 2008 R2 therefore incompatible to initialize the subscriber using a backup. The sites have slow connections so I have always initialized replication from backups.
Would it be possible to drop the replication and recreate it? Replication always seems to be finicky and it might still have remnants of the columns out there (where you can't see it)
Remember you can script the rep so you don't have to start from scratch.
I have been looking into this project for a side-by-side upgrade solution. The most widely suggested/used solution is to do a full back of SQL Server 2000 database and restore on SQL Server 2008 with norecovery. Then restore the subsequent transaction log backups with norecovery. When we are ready to switch, change SQL Server 2000 to read-only mode, backup the tail-log and restore it on SQL Server 2008 with recovery. Then bring SQL Server 2008 online.
But, can't the upgrade be done with transactional replication where SQL Server 2000 is the publisher and SQL Server 2008 is the subscriber. Script all objects such as logins, indexes, etc and apply to SQL Server 2008. When we are ready to switch, we will stop replication, delete all replication jobs, and switch all apps to connect to SQL Server 2008. I haven't found anyone that suggests this method. Is there anything wrong with it?
The method of data migration you describe is possible to perform using SQL Server Replication.
There is nothing wrong with this method or any other data migration method for that matter, so long as the choice you decide upon addresses the specific requirements of your project/application platform.
That said the method you describe is certainly more technically involved in both the configuration and implementation of the actual migration steps. If you can accept downtime, a simple backup and restore process is certainly going to be much more straight forward. Log shipping would also be another simpler migration method.
So far, you know that the replication method could work in theory. Now is the time to build out a working solution in test in order to validate your data migration strategy and to practice the implementation process.
If you aren't replicating otherwise, creating a replication subscription will change your schema and a few settings.
For example, you may end up with GUIDs generated for all your rows just to facilitate the replication.
Caution - transactional replication will turn off all IDENTITY columns at the subscriber (the transactional replication SPs actually depend on this fact, as they insert into the IDENTITY columns without first specifying IDENTITY_INSERT ON). I can only confirm this is the case when the subscriber is SQL 2000 as well - perhaps the subscriber on 2008 will behave differently.
For this reason, transactional replication with SQL 2K doesn't really give you a hot standby. We had to do a fair bit of SQL tweaking (re-instating the IDENTITY columns & re-writing the replication SPs with IDENTITY_INSERT wrappers) to get ourselves a situation where the subscriber actually works as a hot standby, ready to have applications pointed at it. But it certainly wouldn't work out of the box =)
Yes, it will work, provided that you transfer the other objects over.
I've got a new client, blah blah blah, I need to break SQL Server 2000 replication from their home office to another database that they are going to completely drop (at some hosting place, it is no longer needed).
The one at the home office is the "Publisher", I believe. Honestly, I think we could just delete the other database and the home office one would run fine, but it would be nice to clean it up a bit and get rid of the publications/subscriptions stuff.
The one issues I'm concerned about is the identity insert. On tables with an auto-assigned integer primary key, each database would "reserve" a block of ids that it would use so they wouldn't trample on each other when synching up.
So, if I just dump the replication stuff, will the database insert happily until it hits the upper bound of its auto-number range? What happens then?
You need to clearly identify the roles that each Database and Server are playing in your replication topology before you start rolling out any changes.
As a further precaution, I would also suggest that you script out your Replication Configuration, so that you have a reference of it for safe keeping.
For details on how to correctly remove a specific replication role i.e. Subscriber / publisher / Distributor.
See Books Online: Removing Replication
Environment:
SQL Server 2005 SP2 (9.0.3077)
Transactional Publications (Production and Beta)
I have a situation where I have two different Replication Publications setup that use some of the same Articles. Each of these Publications feeds a subscriber on a different machine. One of these shared Articles is a table. At a regular time interval many of the records in this table become aged and no longer needed. At this time a stored procedure that deletes records is called.
To save on resources and improve latency times to the subscribers I have set the replicate property on this stored procedure to “Execution of the stored procedure” instead of the default “Stored procedure definition only”. This way when the stored procedure deletes 2,000,000+ records these don’t replicate down to the subscribers. Instead the execution of the stored procedure is replicated and the same replicated stored procedure on the subscribers is executed and it deletes the same 2,000,000+ rows.
The problem I’m having is with my second publication. I didn’t need this type of behavior so I left the article property on the stored procedure set to “Stored procedure definition only” and was expecting replication to remove the rows at the other subscriber but it wasn’t. The table at the subscriber just kept gaining records. So to fix it I set the Article Property to "Execution..." and called it good. Which is probably the best solution so beta matches production, but it still feels like a kludge as the publication properties should work independently of each other.
Question: Why does the “Execution of the stored procedure” article property take precedence and get applied to the other publication even though it is set to “Stored procedure definition only” in the other publication?
We use replication extensively in our company as we have 38 warehouses in several countries all replicating back to our primary server in London.
Firstly, your replication filters should use Views, even the simple ones. That way, if you need to adjust the filter (read WHERE clause), you just need to alter the view and your done. Otherwise you have to re-publish your data, and re-subscribe everyone which can be a real pain.
You mentioned that you run the same delete on both subscriber and publisher to keep them in-sync. This sends shivers down my spine. Your far better off deleting them in one place and letting the server replicate out to the subscribers the changes made. Since SQL Server 2005, replication is very fast and efficient now. SQL 2000 was and is quite slow for replication. If your using SQL 2005/2008, just make sure your compatibility level (right click on db, properties, options) is set to 90 (2005) or 100 (2008). This switches sql server over to the fast and efficient replication methods.
Another way is to not delete the data, but to keep it and filter it out using a where clause in the publication.
It has been a long time since I actively administered replication but I suspect the answer has to do with the architecture of the log-reader and that you are sharing an article between publications. My understanding is that the log-reader will trawl through the log and look for operations on items that are replicated. Depending on the article settings, the individual changes to the data may be posted to a table in the distribution database or a record of the procedure invocation will be posted. In any case, this is a property of the article and not the publication(s) that the article is a member of. I assume (but have not tested and verified) that you can create multiple articles on top of the same database object and have one be replicated with #type='logbased' and the other with #type='proc exec'
Take all of this with a large pinch of salt: although I now develop on SQL 2008, the last time I did anything with replication was SQL 7.
pjjH