August 13, 2014 at 6:08 am
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???
August 13, 2014 at 7:23 am
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!
August 13, 2014 at 7:23 am
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.
Rick
Disaster Recovery = Backup ( Backup ( Your Backup ) )
August 13, 2014 at 7:56 am
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.
August 13, 2014 at 8:09 am
patrickmcginnis59 10839 (8/13/2014)
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!
Correct:
MSDTC = Microsoft Distributed Transaction Coordinator (COM Transaction Manager)
MSDE = Microsoft Database Engine
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
August 13, 2014 at 8:17 am
Brandon J Williams (8/12/2014)
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.
Disagree as in the past I have used SQL 2000 replication on quite a decent backend, with a good, reliable network it was still poor (hence my signature).
Granted in SQL 2008/2012 it has become a bit more robust and yes totally agree when it does work it is fantastic, but going back to the original editorial, it does seem that nothing has been spent on enhancing SQL Server Replication. Just check the number of articles bemoaning the limitations of replication monitor. Come on M$ start listening!
qh
August 13, 2014 at 8:33 am
patrickmcginnis59 10839 (8/13/2014)
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!
Yes, that's right . I was trying to remember the abbreviation for MS Desk Top Engine and picked DT for Desk Top and forgot that Engine doesn't start with C because when I type DT the following C is automatic. :blush:
DTC was Distributed Transaction Coordinator, of course.
edit:fxi teh sepllign
Tom
August 13, 2014 at 10:24 am
quackhandle1975 (8/13/2014)
Brandon J Williams (8/12/2014)
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.Disagree as in the past I have used SQL 2000 replication on quite a decent backend, with a good, reliable network it was still poor (hence my signature).
Granted in SQL 2008/2012 it has become a bit more robust and yes totally agree when it does work it is fantastic, but going back to the original editorial, it does seem that nothing has been spent on enhancing SQL Server Replication. Just check the number of articles bemoaning the limitations of replication monitor. Come on M$ start listening!
qh
I am unsure about SQL 2000 as that was before my time, but I have a mix of 2005 - 2012 topologies with a few thousand publications/subscriptions for a couple of large retail store chains that operate largely maintenance free. There are 2 of us that manage this.
I agree about Microsoft not actively developing for replication at the moment, it seems like they have been focusing on other features as of late.
Replication Monitor is good for a quick sanity check but we have rolled our own monitoring solution. We are continuously adding features to that.
August 13, 2014 at 11:05 am
Robert.Sterbal (8/13/2014)
Brandon,The posts in this forum suggest otherwise.
That's why I'm here to set the record straight.
Most of the issues I'm reading about would be helped by better reporting of replication status and easier replication repair.
Agreed. We realized early on we needed a more robust monitoring solution so we rolled our own.
Regarding replication repair, there are several ways to approach this, both proactive and reactive. Some approaches that have worked for us:
- Enabling verbose agent logging for more details.
- The ability to reinitialize subscriptions quickly, there are techniques to accomplish this. We've almost turned it into a competition to see who can reinitialize the fastest.
- The ability to compare and generate scripts that manually bring 1 or more databases into convergence. There are tools to help with this.
- Warm standbys for subscribers that fail due to hardware or some other reason. This can essentially be a backup subscription on another instance sitting right next to the primary subscription.
- Cold standbys for publishers that fail due to hardware or some other reason. This involves restoring the master, msdb, distribution, and publication databases to the cold standby using the keep replication switch and the standby needs to have the same name as the original publisher.
August 13, 2014 at 12:37 pm
Brandon,
"That's why I'm here to set the record straight."
Arrogant much?
The clear implication is that your own experience trumps that of anyone else because they must be a "replication novice". And that in spite of multiple other people who agree.
It sounds like to me you've done a whole lot of extra work to get your stable replication environments. You proved our point for us.
August 13, 2014 at 2:02 pm
dstinson-1008865 (8/13/2014)
Arrogant much?
The clear implication is that your own experience trumps that of anyone else because they must be a "replication novice". And that in spite of multiple other people who agree.
It sounds like to me you've done a whole lot of extra work to get your stable replication environments. You proved our point for us.
This has nothing to do with arrogance. And my experience does not trump anything.
My point is that replication novices are quick to point the finger at replication when it's not replication that is the problem.
We actually haven't done much in the way of getting a stable replication environment, it just works. Sure, we've read BOL, but as far as getting it stable, that's it.
August 13, 2014 at 2:13 pm
And back to Steve's point, I do wish they had focused on enhancing peer-to-peer. especially the monitoring.
The more you are prepared, the less you need it.
August 13, 2014 at 7:53 pm
Brandon J Williams (8/13/2014)
Replication Monitor is good for a quick sanity check but we have rolled our own monitoring solution. We are continuously adding features to that.
That seems to say that you agree with those of us who thought it needed improvement, which is a big switch from what you said earlier. If it didn't need improvement, why would you roll your own instead of making do with what was provided?
It reads like exactly what I did with replication in SQLS 2000, except that my monitor attempted to take remedial action when it thought there was something wrong, as well as reporting.
Tom
August 13, 2014 at 8:37 pm
TomThomson (8/13/2014)
Brandon J Williams (8/13/2014)
Replication Monitor is good for a quick sanity check but we have rolled our own monitoring solution. We are continuously adding features to that.That seems to say that you agree with those of us who thought it needed improvement, which is a big switch from what you said earlier. If it didn't need improvement, why would you roll your own instead of making do with what was provided?
It reads like exactly what I did with replication in SQLS 2000, except that my monitor attempted to take remedial action when it thought there was something wrong, as well as reporting.
No switch. I said that replication is not brittle, buggy, or unstable.
We rolled our own monitoring solution because we have a lot of separate, independent replication topologies out in production and we needed a way to centrally monitor all of them. We ended up integrating this custom monitoring solution with our existing application error log, so we can monitor everything from one place.
August 14, 2014 at 8:07 am
Brandon J Williams (8/13/2014)
My point is that replication novices are quick to point the finger at replication when it's not replication that is the problem.We actually haven't done much in the way of getting a stable replication environment, it just works. Sure, we've read BOL, but as far as getting it stable, that's it.
You're conflating your experience with the capability or robustness of replication. I've had to be stable in places, I've had it inexplicably fail. Certainly some of the failures have to do with a lack of bandwidth, or maybe disk space, or networking, or data, or something else.
However that's where replication is brittle. It will fail with things that shouldn't cause it to fail. Just because it hasn't for you, doesn't mean it can't or won't. The fact you reinitialize subscriptions leads to my point that it has plenty of room for improvement (along with other features).
Viewing 15 posts - 16 through 30 (of 38 total)
You must be logged in to reply to this topic. Login to reply