SQL Clone
SQLServerCentral is supported by Redgate
 
Log in  ::  Register  ::  Not logged in
 
 
 


Best one-way replication option going forward


Best one-way replication option going forward

Author
Message
ESpigle
ESpigle
Valued Member
Valued Member (69 reputation)Valued Member (69 reputation)Valued Member (69 reputation)Valued Member (69 reputation)Valued Member (69 reputation)Valued Member (69 reputation)Valued Member (69 reputation)Valued Member (69 reputation)

Group: General Forum Members
Points: 69 Visits: 132
I'm looking for some insight into implementing replication with a SQL 2005 Standard database based on our needs as well as the fact that one major replication type is deprecated in SQL 2012 and forward. To start off with, let me briefly describe what our replication needs are and what replication method I think is best for that... and why we don't want to use it. I'll also state that I have never dealt with SQL replication, so I'm learning as I go here.

We have a single SQL database server that drives all of our production data for our company. We are wanting to setup a second read-only database server that we replicate to to help load balance for some specific applications that will be fairly intense with the database. This second SQL server is always online, on the same network and as mentioned will be read only--no sending data back to the primary server. Updates need to happen as data changes on the primary server.

It seems fairly obvious to me that based on the above that we should use updatable subscriptions for transactional replication. However, this feature is deprecated in SQL 2012. Our IT manager wants to use something that's future proof, so she said out with this method. When we'll ever upgrade our SQL 2005 Standard installation, who knows. It could be many years. The only other real method that seems viable is merge replication. That isn't deprecated in SQL 2012. Peer-to-peer is what Microsoft seems to says is the replacement for updatable subscriptions for transactional replication, but we're not going to upgrade to enterprise for this feature.

My question is: what are the downsides for using merge replication for a scenario like the above where clearly it seems updatable subscriptions for transactional replication is better. Can we effectively make Merge Replication work in a similar fashion to updatable subscriptions for transactional replication and avoid updates being pushed to the publisher? Are there any performance issues to consider? ...or other caveats for that matter?

Thanks for any insights on the matter.
Evil Kraig F
Evil Kraig F
SSC-Insane
SSC-Insane (20K reputation)SSC-Insane (20K reputation)SSC-Insane (20K reputation)SSC-Insane (20K reputation)SSC-Insane (20K reputation)SSC-Insane (20K reputation)SSC-Insane (20K reputation)SSC-Insane (20K reputation)

Group: General Forum Members
Points: 20879 Visits: 7660
Since you're doing a full database replication instead of selective, I'd actually recommend using mirror/snapshot. It's basically easy-mode transactional replication. Check it out; it's definately future proof as it's part of the HA-DR methodology SQL wants to implement.

A mighty quick walkthrough of how to do the setup:
http://weblogs.sqlteam.com/tarad/archive/2007/02/13/60091.aspx


- Craig Farrell

Never stop learning, even if it hurts. Ego bruises are practically mandatory as you learn unless you've never risked enough to make a mistake.

For better assistance in answering your questions | Forum Netiquette
For index/tuning help, follow these directions. |Tally Tables

Twitter: @AnyWayDBA
ESpigle
ESpigle
Valued Member
Valued Member (69 reputation)Valued Member (69 reputation)Valued Member (69 reputation)Valued Member (69 reputation)Valued Member (69 reputation)Valued Member (69 reputation)Valued Member (69 reputation)Valued Member (69 reputation)

Group: General Forum Members
Points: 69 Visits: 132
Interesting--I had not really looked at or considered that option. I'll have to dig around for some more extensive information and howtos on doing this. The link you gave seems to indicate the mirrored DB wouldn't be usable because of being set to norecovery, but it just looks like I have to find the right setup with snapshots to get what I need.

Thanks--this gives me a new rabbit trail to go down.

EDIT: It looks like this option is out. Snapshots aren't a feature of SQL 2005 Standard edition. We won't be dropping the money on Enterprise--that I know.
Evil Kraig F
Evil Kraig F
SSC-Insane
SSC-Insane (20K reputation)SSC-Insane (20K reputation)SSC-Insane (20K reputation)SSC-Insane (20K reputation)SSC-Insane (20K reputation)SSC-Insane (20K reputation)SSC-Insane (20K reputation)SSC-Insane (20K reputation)

Group: General Forum Members
Points: 20879 Visits: 7660
ESpigle (8/16/2012)
Interesting--I had not really looked at or considered that option. I'll have to dig around for some more extensive information and howtos on doing this. The link you gave seems to indicate the mirrored DB wouldn't be usable because of being set to norecovery, but it just looks like I have to find the right setup with snapshots to get what I need.

Thanks--this gives me a new rabbit trail to go down.

EDIT: It looks like this option is out. Snapshots aren't a feature of SQL 2005 Standard edition. We won't be dropping the money on Enterprise--that I know.


My pleasure and dead on target. The mirror isn't directly usable. What you do is snapshot it at certain time periods to 'upkeep' it. Snapshots are usually pretty quick. If you want to get particularly fancy you setup a full warehouse alongside the mirror/snapshot setup. Every x period your updater runs, creates a new snapshot, evaluates the delta, and includes it into the reporting warehouse without user interuption. :-)

... and I just caught your edit. Well, that sucks. Um, hrm. Log shipping then?

EDIT: Btw, I'd avoid merge replication like the plague. If you NEED merge, it's the only way to go, but it's such a PITA that I'd avoid it unless absolutely necessary.


- Craig Farrell

Never stop learning, even if it hurts. Ego bruises are practically mandatory as you learn unless you've never risked enough to make a mistake.

For better assistance in answering your questions | Forum Netiquette
For index/tuning help, follow these directions. |Tally Tables

Twitter: @AnyWayDBA
ESpigle
ESpigle
Valued Member
Valued Member (69 reputation)Valued Member (69 reputation)Valued Member (69 reputation)Valued Member (69 reputation)Valued Member (69 reputation)Valued Member (69 reputation)Valued Member (69 reputation)Valued Member (69 reputation)

Group: General Forum Members
Points: 69 Visits: 132
Evil Kraig F (8/16/2012)
EDIT: Btw, I'd avoid merge replication like the plague. If you NEED merge, it's the only way to go, but it's such a PITA that I'd avoid it unless absolutely necessary.


We don't really need it, per se. It was just one of the options we saw that was not being done away with for future SQL versions. Already with just some initial testing I can see we're going to have many roadblocks just to make it work base on various things with the database structure and setup.
Evil Kraig F
Evil Kraig F
SSC-Insane
SSC-Insane (20K reputation)SSC-Insane (20K reputation)SSC-Insane (20K reputation)SSC-Insane (20K reputation)SSC-Insane (20K reputation)SSC-Insane (20K reputation)SSC-Insane (20K reputation)SSC-Insane (20K reputation)

Group: General Forum Members
Points: 20879 Visits: 7660
How up to date does the copy need to be kept? Snapshot replication isn't going anywhere anytime soon as far as I know, and should work in standard.

... which, at that point, you might just look into backup/restores to the other server. Sorry, scrap that. Not that it's a bad idea (testing your restores is always good), just probably too much downtime if you aren't looking for 'one day behind' upkeep.


- Craig Farrell

Never stop learning, even if it hurts. Ego bruises are practically mandatory as you learn unless you've never risked enough to make a mistake.

For better assistance in answering your questions | Forum Netiquette
For index/tuning help, follow these directions. |Tally Tables

Twitter: @AnyWayDBA
MissTippsInOz
MissTippsInOz
Right there with Babe
Right there with Babe (799 reputation)Right there with Babe (799 reputation)Right there with Babe (799 reputation)Right there with Babe (799 reputation)Right there with Babe (799 reputation)Right there with Babe (799 reputation)Right there with Babe (799 reputation)Right there with Babe (799 reputation)

Group: General Forum Members
Points: 799 Visits: 597
ESpigle (8/16/2012)
We are wanting to setup a second read-only database server that we replicate to to help load balance for some specific applications that will be fairly intense with the database. This second SQL server is always online, on the same network and as mentioned will be read only--no sending data back to the primary server. Updates need to happen as data changes on the primary server.


Reading your initial requirements I'm not sure why you need to configure transactional replication with updateable subscriptions. You have said that your replicated database will be read-only, so surely no need for an updateable subscription?

Clare
_________________________________________________________________________________________________________________
Measure twice; cut once (and have a good saw)

Hey, just a thought.....did you check Books Online yet?
ESpigle
ESpigle
Valued Member
Valued Member (69 reputation)Valued Member (69 reputation)Valued Member (69 reputation)Valued Member (69 reputation)Valued Member (69 reputation)Valued Member (69 reputation)Valued Member (69 reputation)Valued Member (69 reputation)

Group: General Forum Members
Points: 69 Visits: 132
I'm still trying to get a grasp on all the ways to get data from one server to be matched on another for application load balancing, so what you say may be entirely true. I'm at the learning about the various ways to accomplish this stage, so I've definitely not settled on one way while I'm trying to figure out how it all works. I'm still researching my options that are available for a SQL 2005 Standard setup.
Jeff Moden
Jeff Moden
SSC Guru
SSC Guru (217K reputation)SSC Guru (217K reputation)SSC Guru (217K reputation)SSC Guru (217K reputation)SSC Guru (217K reputation)SSC Guru (217K reputation)SSC Guru (217K reputation)SSC Guru (217K reputation)

Group: General Forum Members
Points: 217230 Visits: 41991
I don't know the details of how it all works but we use SAN replication on a realtime basis to send transactions to our DR site. It's awfully fast and requires nothing of the SQL server.

--Jeff Moden

RBAR is pronounced ree-bar and is a Modenism for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column.
If you think its expensive to hire a professional to do the job, wait until you hire an amateur. -- Red Adair

Helpful Links:
How to post code problems
How to post performance problems
Forum FAQs
MissTippsInOz
MissTippsInOz
Right there with Babe
Right there with Babe (799 reputation)Right there with Babe (799 reputation)Right there with Babe (799 reputation)Right there with Babe (799 reputation)Right there with Babe (799 reputation)Right there with Babe (799 reputation)Right there with Babe (799 reputation)Right there with Babe (799 reputation)

Group: General Forum Members
Points: 799 Visits: 597
Do you actually have the replicated DB online Jeff? I've used a couple of flavours of SAN replication but the database is not actually mounted at the other end

Clare
_________________________________________________________________________________________________________________
Measure twice; cut once (and have a good saw)

Hey, just a thought.....did you check Books Online yet?
Go


Permissions

You can't post new topics.
You can't post topic replies.
You can't post new polls.
You can't post replies to polls.
You can't edit your own topics.
You can't delete your own topics.
You can't edit other topics.
You can't delete other topics.
You can't edit your own posts.
You can't edit other posts.
You can't delete your own posts.
You can't delete other posts.
You can't post events.
You can't edit your own events.
You can't edit other events.
You can't delete your own events.
You can't delete other events.
You can't send private messages.
You can't send emails.
You can read topics.
You can't vote in polls.
You can't upload attachments.
You can download attachments.
You can't post HTML code.
You can't edit HTML code.
You can't post IFCode.
You can't post JavaScript.
You can post emoticons.
You can't post or upload images.

Select a forum

































































































































































SQLServerCentral


Search