Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase ««1234»»»

The Brittleness of Replication Expand / Collapse
Author
Message
Posted Tuesday, August 12, 2014 3:17 PM
SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: 2 days ago @ 10:44 AM
Points: 2,902, Visits: 1,817
What about full text search. It could have been good but the Solr/ElasticSearch horse has well and truly bolted.

LinkedIn Profile
Newbie on www.simple-talk.com
Post #1602498
Posted Tuesday, August 12, 2014 5:22 PM


SSCrazy Eights

SSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy Eights

Group: General Forum Members
Last Login: Today @ 3:33 PM
Points: 8,826, Visits: 9,385
I used replication a lot for about 7 years. This was all transactional replication, except for some(very little) ad-hoc snapshot replication. It certainly had some defects. I called it fragile, rather than brittle, because when it broke one generally didn't have to clean up the mess and start again from creating publications and subscriptions, one just had to mess about a bit and then get it going again, which only rarely would require even reinitialising a subscription. For many problems it was possible to write monitoring software to detect them and do the mesing about and restart (not reinitialise) a subscription - of course that had to be monitored to make sure that it didn't just keep trying again. But there were some really nasty bugs. MS may have fixed them in later versions - I never used replication on anything later than SQL 2000, except for some quick and dirty checks that what we had done before on 2000 would still work on 2008 - but I suspect not. As well as teh bugs, it was harder to use and manage than it ought to have been; and from what I've seen (and from Steve's article) it seems that MS hasn't done anything to make it easier. That's not a good thing. The documentation was prety terible too, but that may for all I know have improved.

But although replication has not improved as fast as MS's customers would like, MS does a lot better at improving hings than some other software suppliers. I remember one product from CISCO that incorporated MSDTC (the SQL 2000 name for SQL Express without tools). Not only did CISCO not provide enhancements, they didn't fix bugs; and they built the thing in such a way that it was impossible to apply MS's fixes to SQL Server, which was a big problem for anyone who used it. My big problem was that the envirenment in which user software added to the thing had to run had race conditions that were not resolvable in the user software, and CISCO was not going to fix them. But for some of its users perhaps it was an especially big problem early in 2003 when this malware hit the internet, and owners of that product couldn't apply the fix MS provided because they were stuck with SQL Server 2000 RTM and no subsequent SP or fix could be applied. I saw similar (perhaps not as extreme as that one) problems with other products too. So let's not get too upset with MS about not improving everything, some others are worse.


Tom
Post #1602525
Posted Tuesday, August 12, 2014 7:00 PM


SSChasing Mays

SSChasing MaysSSChasing MaysSSChasing MaysSSChasing MaysSSChasing MaysSSChasing MaysSSChasing MaysSSChasing Mays

Group: General Forum Members
Last Login: Yesterday @ 8:09 PM
Points: 631, Visits: 2,193
I hate replication. And I do my best to avoid it if at all possible.

Back in 2002 It was my responsibility to build a DR plan for our SQL servers at our offsite 50 miles away connected by 4 T-1s. So I started the first effort try to use transactional replication to a set of standby databases. It failed the first test and then a month later failed the retest. So it was back to square one.

Then I come to my current company and they built the software to have a master DB at the headquarters and supposedly replicate "universal" data like suppliers and standard codes down to the individual faacility DBs. It would only work on a facility that had at least two solid T-1 connections. Otherwise the facilities had to be co-located on servers at HA and then would RDP into facility or terminal servers. They finally shut it down for lack of customers.

So onto the next SW we produced. It had a master DB and then two they had built two silos of data to try and load balance the customers. They used replication to move data down hill in the individual silos. But they never differentiated the replication so it was duplicating the data in both silos. And taking up the space.

Now when someone says replication it takes all my personal skills not to shudder. If I can avoid it -- I will. I'd rather build everything by had to transfer data from DB to DB.




----------------
Jim P.

A little bit of this and a little byte of that can cause bloatware.
Post #1602534
Posted Tuesday, August 12, 2014 9:10 PM


SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC Rookie

Group: General Forum Members
Last Login: Saturday, September 13, 2014 10:39 AM
Points: 34, Visits: 753
Replication is not brittle, buggy, or unstable. Unreliable network connections can cause replication to fail, and the replication novice will interpret this as a bug or as replication being unstable.
Post #1602546
Posted Tuesday, August 12, 2014 10:47 PM
Grasshopper

GrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopper

Group: General Forum Members
Last Login: Friday, September 12, 2014 2:24 AM
Points: 12, Visits: 93
Replication doesn't work as well as log shipping on small pipes.

I would like to see a better tool set as well, at least to the point of being able to script the changes needed to bring replication up and down.
Post #1602559
Posted Tuesday, August 12, 2014 10:59 PM


SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC Rookie

Group: General Forum Members
Last Login: Saturday, September 13, 2014 10:39 AM
Points: 34, Visits: 753
Log shipping cannot do what replication does.

I agree, over small pipes, or an unreliable or slow network connection, replication may timeout or fail or something like that. But there are replication agent parameters and other replication settings which can mitigate this. This is why proper design and pre-deployment testing is crucial. Microsoft also recommends a fast network of 100 Mbps or faster.

The cool thing is, once a replication solution is designed, tested, and deployed correctly, nothing can beat its synchronization capabilities.
Post #1602563
Posted Wednesday, August 13, 2014 6:08 AM
Say Hey Kid

Say Hey KidSay Hey KidSay Hey KidSay Hey KidSay Hey KidSay Hey KidSay Hey KidSay Hey Kid

Group: General Forum Members
Last Login: Yesterday @ 6:18 AM
Points: 662, Visits: 1,671
Steve concluded with this statement:

"I have to believe there are developers at Microsoft that would love to make the product better. I understand the need for new features, and continuing sales, but devoting a percentage of time to improving existing features, regardless of the Connect votes or marketing wishes, would help make the platform that much better for everyone."

Ask any long time SQL DBA or .NET developer, there are hundreds of low hanging bugs and excellent minor feature requests that get ignored. Then we get interfaces like Windows 8 or Visual Studio 2013 and layoffs that include good folks that are MCMs. WTF Redmond???

Post #1602690
Posted Wednesday, August 13, 2014 7:23 AM
SSC-Addicted

SSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-Addicted

Group: General Forum Members
Last Login: Yesterday @ 6:20 AM
Points: 415, Visits: 2,439

I remember one product from CISCO that incorporated MSDTC (the SQL 2000 name for SQL Express without tools).

<nitpick>MSDE</nitpick>

MSDTC is the transaction manager isn't it? Just being picky about an otherwise informative comment!
Post #1602722
Posted Wednesday, August 13, 2014 7:23 AM
Valued Member

Valued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued Member

Group: General Forum Members
Last Login: Sunday, August 17, 2014 8:22 AM
Points: 58, Visits: 187
Replication, like so many other features, does need to be continuously updated and improved. I used replication also from version 6.5 to move custom pricing and billing data for national accounts around the 48 states to provide consolidated billing. And we were moving large quantities of data. There were many failures and retransmissions mostly due to phone system quality. Many times we had to stop the process and resync via overnighting large datasets at a known point in time.

I can't speak to current replication because I never used it after version 7, but the multimillion dollar project eventually died mostly due to the lack of adequate attention to problems.

Sometimes it seems that new features are more to spread product to geeks than to support heavy users. We don't need all the latest toys, just a solid platform and good performance. Further, it's easier to sell management on 'new and better' than to sell them on need for maintenance and improvement and bug fixing.

I think you are right about the people at Microsoft and elsewhere who are still out there and want to make the fixes and improvements and who care about accuracy and dependability. But they probably often have the experience I had in one position where the stated priority of the owner of the company was that data will be AVAILABLE, even if not ACCURATE.

In my last position, I had quite a number of fixes to proven inaccuracies in systems which timid Project Managers would not implement because of what they perceived as risk in changing the system.
Post #1602723
Posted Wednesday, August 13, 2014 7:56 AM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Yesterday @ 11:29 AM
Points: 158, Visits: 1,800
Brandon,

The posts in this forum suggest otherwise.

We use replication at hundreds of sites, yet fail to use it to get a near real time archive of our in house CRM system (We do a database update at 2 am every day).

Log shipping doesn't replace all of replication's features, it provides an alternate way of solving a problem on a small pipe.

Most of the issues I'm reading about would be helped by better reporting of replication status and easier replication repair.
Post #1602737
« Prev Topic | Next Topic »

Add to briefcase ««1234»»»

Permissions Expand / Collapse