August 2, 2005 at 6:09 pm
Comments posted to this topic are about the content posted at http://www.sqlservercentral.com/columnists/crock/adventuresinreplication.asp
_______________
Convert DTS to SSIS | Database Documentation | SSIS Performance | SSIS Monitoring
August 22, 2005 at 1:58 am
Good article!
We are thinking that at some stage we would let people sync data from our doc management system (normally hosted on a server at the customer's premises) with people's laptops so that they can make changes and then "merge" them when they come back.
It is stories like this that make me wonder if it is worth the trouble. Has anyone had lots of experience with this sort of environment? - bear in mind that a lot of the people with the laptops will be doctors (not very technically mined and not usually patient to wait for things to complete)
Is it easier to "roll your own" for some of these things?
August 22, 2005 at 5:23 am
That's a design decision that should be thought of very carefully. Rolling your own may be the way to go if you do not have time to get to understand merge replication.
It would benefit you to take a look at it. You can control replication using the sql dmo objects (smo in 2005).
The great thing about merge replication is it works. It has the built-in conflict resolution so you do not have to write that piece of code.
_______________
Convert DTS to SSIS | Database Documentation | SSIS Performance | SSIS Monitoring
August 22, 2005 at 6:04 am
There is a often underlooked replication option available in MSSQL 2000 called "Attach & Go", this allows you to take a local replicated database and "Attach" it to a remote machine and you should be good. The key words to look up in BOL are "sp_copysubscription" and "sp_attachsubscription". These keywords should get you going to see if it would apply, the nice benefit of these are that there are no remote BCP of snapshots, and no daily/weekly snapshots needed (if you want them). As long as your local copy of the replicated database is up to date. [I've had great sucess with with, but I've only really used transactional replication. The approach is a lifesaver as it misses all the DB contention when dealing with snapshots]
Finally now I've hopefully wetted your appetites, there is the age old computer question...
Q: What is the fastest way to move 50Mb/1Tb/50Tb from one datacenter to another 50 miles away. VPN/FTP/Compressed etc?
A: Stick it in a car/truck and drive it! [Preferably on an attachable drive rather than tapes]
Obviously I have no idea if that approach would have applied in this case (physical security etc), but if you need to get a system up quickly that is often the fastest way and is most commonly overlooked in our connected world 🙂
August 22, 2005 at 6:16 am
An update on the article. When I wrote this I didn't know why the subscription became inactive. With a little search on google I think I located the problem.
In the distribution database properties there is a setting labeled "Transaction retention" which allows you to set the number of hours the transactions should be kept in the distribution database. After this time expires and subscription hasn't been attended to, the message received will be "The subscription(s) have been marked inactive and must be reinitialized."
I hope this helps someone down the road.
_______________
Convert DTS to SSIS | Database Documentation | SSIS Performance | SSIS Monitoring
August 22, 2005 at 7:16 am
Lesson #7: Find the CAUSE first!
* Noel
August 22, 2005 at 7:47 am
Exactly! I'm hoping that others learn from my mistakes.
_______________
Convert DTS to SSIS | Database Documentation | SSIS Performance | SSIS Monitoring
August 22, 2005 at 7:53 am
Thanks 4 the advice... Wasn't aware of that attaching trick - shall keep it in mind for future.
A cause is always lovely to find, but the fix is the one that makes you look good
August 22, 2005 at 10:40 am
That was actually something we were looking at. If replication wouldn't have succeeded, we were driving it down there. 🙂
Fortunately, in the end, everything worked out.
_______________
Convert DTS to SSIS | Database Documentation | SSIS Performance | SSIS Monitoring
August 23, 2005 at 11:01 am
Ok so you are learning the practicality of a replicated and massive database between distant site. You have practiced the exercise and this is good. But if this happened again next month its my advice that you pickup the 80mile distant server (2 hours), use a local network (ie: crossover cable between the servers 2nd nics) and perform the replication in person at 100mbit or 1000mbit speed.
If you end up having to do the driving... 1 it gets you out of the office so you can do some mental regrouping, 2 you will treat that 2nd db server like a fragile egg, 3 you will be encouraged to get the whole deal done with so you can get your lifeback after you return the machine to its proper site location.
You know the technical aspects due to the experience but when you measure it next to the alternatives: Time... Time... Time... (2.5 days to rep 2 tables and all the other tables... next time there will be that much more data)
save yourself Chris
Sean
August 23, 2005 at 2:18 pm
The only problem with that plan is it's not a 2 hours drive. It's more like a 4-5 hour drive. Construction...
I do get what you're saying though.
Thanks for the advice.
_______________
Convert DTS to SSIS | Database Documentation | SSIS Performance | SSIS Monitoring
September 9, 2005 at 2:42 pm
Hey Chris,
You need to get some SQL books to sit on your shelf with the C++ ones you currently have on there...
Good job getting it done though, "Tom"'s really proud of you.
Viewing 12 posts - 1 through 11 (of 11 total)
You must be logged in to reply to this topic. Login to reply