October 5, 2002 at 12:00 am
Comments posted to this topic are about the content posted at http://www.sqlservercentral.com/columnists/awarren/snapshotreplication.asp>http://www.sqlservercentral.com/columnists/awarren/snapshotreplication.asp
October 10, 2002 at 12:55 am
we use snapshot replication because we do not require the most recent data and the data at the publisher changes once a day/couple of times a week and these are mostly lookup tables and the Subscribers can be disconnected totally if they are not updating.
--Ramesh
Sydney
Edited by - ramesh on 10/10/2002 12:56:40 AM
Ramesh
October 10, 2002 at 4:11 am
I've used transactional where ever possible. However, I am using Snaphot in one case - our database is duplicated to SQLBase. SQLBase ODBC drivers just don't support Transactional! (7.0.1 if anyones interested.)
October 10, 2002 at 7:27 am
In this time of zero latency between systems, snapshot does seem a bit outdated.
But you were right-on with the focus on Business requirements. In many of the large corporations I have worked with, it is not uncommon for management systems to be refreshed only once a week. These are usually centralized datawarehouses - pulling in data from diverse regions and OLTP systems. Even if they went to daily refresh, a snapshot or other type of full refresh is usually in order.
If you are a database professional,
business requirements are preeminent.
What's the business problem you're trying to solve?
October 11, 2002 at 5:40 am
I use snapshots when I need to duplicate a live environment for testing purposes.
1. Receive change request.
2. Snapshot the live to a development machine.
3. Test on the development machine.
4. Make amendments to the development machine and test.
5. Apply to live.
6. GOTO 1.
October 14, 2002 at 1:07 am
I use transactional replication to gather data fom 33 different SQL servers. A snapshot would be totally useless hense to bandwith issues.
October 23, 2002 at 7:59 am
We use snapshot replication. The client is creating a schedule throughout the day. They have to explicitly publish the schedule when it is done, which is a one-shot deal each day and has to be undert he control of the user. I have set up a push [only] subscription.Then I wrote a vb6 app that with the push of ONE button, runs some queries, then executes snapshot.exe (creating a snapshot of the resulting tables from the queries) and lastly runs the distribution object to publish to the web database. It took a LOT of time to learn what I needed to solve this problem, but it has worked out beautifully for the client.
October 23, 2002 at 4:37 pm
October 28, 2002 at 8:26 am
This article is very good, The only Unknown variable to me, (having no experinece on replication) is Performance Issues.
What are the performance issues associated with all types of replication ?
Thanks
October 28, 2002 at 1:28 pm
Replication is good but it can be daunting if you dont know how to do it right, believe me you only get one chance to get it right.
My experience with replication is, if you don't need to query the data on the remote server, use Log-Shipping instead, keep it as a StandBy.
Use transactional replication, it takes a little bit more work than snapshot but bandwith wise is the way to go, unless you have gigabit ethernet all over your network or you dont really move that much traffic on your db.
Performance wise get a good server, specially the one where you put the distributor, the db itself won't choke but your performance will take a hit, anything that takes cpu cyles and memory address space affects performance.
And if you have the dough and want to get real fancy, get Legato RepliStor or Legato Co-Standby, This are the best tools, I've used them both and they are a snap to configure and administer. All your data is replicated instantly and you get a cluster/ failover environment that works like a champ. This tools are some real jewels.
Hope this helps
Gerald Nelson MCP/MCDBA
Gerald Nelson MCP/MCDBA
October 28, 2002 at 5:59 pm
I agree that using replication does take some additional horsepower - how much is hard to quantify. For transaction, you can kind of picture the server workload by thinking about steps:
- Log reader in memory, scanning transaction log. Uses memory, definitely some disk io, probably minimal cpu, then does an insert into distribution - which is also a logged operation and hits the disk again. Fairly cheap I'd say.
- Distribution has to pick up transactions out of the db, apply them, mark as done, so you're doing some updates/deletes, everything logged again.
- Network bandwidth to push changes. Not bad unless you do lots of bulk updates or have to push a snapshot. Replicating stored procedure calls instead of the actual updates can reduce this some as well.
Gerald: Have not had the chance to work with either of those products, would like to hear more. Feel like submitting a review of either/both?
Andy
September 25, 2003 at 6:49 am
Are organization has been struggling with which replication to use. Are there any articles out there that have been written for specific replication architecture based on specific industries? We are in the health care industry and we have developed an application whereby users that are on our WAN use a internal application built in IIS. But when users go off the WAN then they are using an isolated version of the IIS app and SQL on there own laptops. Currently we are using merge replication for most if not all of our DB’s used to run the application. The problem is that we have had to script out some ugliness in order to run the Merge agent to determine when a user gets on the network in order to invoke the agent to start merge replication. The job is run every minute so once the users get back on the network there data begins to be merged back to the central database. Its seams clunky to do it this way however are users are not savvy enough to have to try and remember to hit a button in order to invoke a sync. Its important to remember that when the users are in isolation mode they are changing the data constantly where records are being added, deleted, updated, ect…
If anyone out there has any ideas, or can point us in a more detailed level towards how we should be doing this, that would be great. Most of what we have read has been to high level and not enough detail for us to clearly define how we should be doing this
Thanks folks!
September 26, 2003 at 5:46 am
I don't remember seeing anything written that targets specific industries. As far as your solution, it doesn't seem bad to me at all. Merge is perfect for disconnected users and it's certainly better to make the sync transparent when they finally do reconnect.
Andy
January 22, 2004 at 12:55 pm
My replication scenario is probably different than 99.9% of people. We use a replicated environment to act as a source control of the data in the database. We have people working in multiple languages that change the data and then "Check it in" to the publisher. They then get to a point where they sign off on the data and "Branch" it. This is accomplished by using merge replication from the publisher to the development machines (using a dynamic snapshot on the merge agent thus allowing them to filter the data for only their language) and snapshot replication from the publisher to the mirror databases for each language. Since the snapshot is only done once every couple weeks it really doesn't need to be anything other than snapshot replication. The whole thing has been automated in the tool they use for editing the data. The only times I have a problem with this scenario is when the managed identities I inherited get out of sync. When that happens I end up repairing a lot of data! Luckily that rarely happens anymore.
Gary Johnson
Microsoft Natural Language Group
DBA, Sr. DB Engineer
This posting is provided "AS IS" with no warranties, and confers no rights. The opinions expressed in this post are my own and may not reflect that of my employer.
Viewing 14 posts - 1 through 13 (of 13 total)
You must be logged in to reply to this topic. Login to reply