April 18, 2008 at 10:49 am
That's an excellent point about the difference between log shipping and transactional replication - the latter does guarantee transactional consistency. I guess my point was that it isn't the easiest thing (especially if it set to continual replication) to determine exactly *what* that transactionally consistent state is (what made it over there last). Log Shipping is much more primitive, but when talking with business users and upper management it is easier to say "It will have lost 15 minutes of data" than X was the last transaction to get replicated.
Still, point taken, and a valid one. My stance on Log Shipping vs Transactional replication for DR purposes only is a controversial one. Still, transactional replication used for more than just DR (that would be a secondary or tertiary role) like have it for reporting servers and such is an excellent idea. And it's an excellent technology.
Thanks for including that point - I think it is important that people understand the pros and cons with each situation. There isn't a definitive answer for most of these topics.
April 29, 2008 at 2:05 pm
James Luetkehoelter (4/17/2008)
A great article, but...I fundamentally disagree with using replication as a DR technique. Even with 2005, I've run into too many clients that often use replication to keep a standby database but find it difficult in the event of a failure (usually because they aren't prepared) to determine the transactional status of the database - is it current up to what point?
I know that's controversial, but, that's my take. It's also a very "busy" technology that has lots of spots of other failure (usually through misconfiguration). My preference is either low-tech log-shipping, or database mirroring.
Still, an excellent article! I'm just playing devil's advocate.
I have totally agree with you here (great article and that TR is not great for DR 😀 )
If we assume transactional replication is setup perfectly and working, we still need to take your article a bit further and talk about how we would cutover the subscriber database to be the production database? And how we would get the original publishing db back in synch when it was ready to resume its role as primray? Another key consideration would be how much down time we need to make all these switches.
Viewing 2 posts - 16 through 16 (of 16 total)
You must be logged in to reply to this topic. Login to reply