quote:I did like the article in general, although if I wanted a really fast method to transfer databases > 2 GB, I would not use this method. sp_attach is a good way to transfer databases when downtime isn't the primary concern, although in the environment I work in, we would not be able to use it. When we need to move a database from one server to the other with as little downtime as possible, we replicate as often as possible before the transfer. Then we take the old server down after one last replication and restore it to the other server. The setup for this process takes a long time, although we can get away with downtime less than 5 minutes. With sp_attach, the file copy would take a long time.
Nice article. I'd like to see more practical ones such as this.
One small point - timestamp. If you're moving tables between servers then you may get duplicate timestamp data when attaching. Timestamps are meant to be unique to a server.
great article from Chris Kempster!
I like his approach of divide into 3 methods with t/sql code.
It is quite useful for my environment, since most files are < 2 gb due archiving periodically.
I did not know that there is a way to take a database off-line with [exec sp_dboption N'mydb', N'offline', N'true'].
thanks
-D
I would like to suggest that the article should have included you basic backup and restore as your first choice for moving databases.
There is no down time on your source system and I'm not sure that a detach, copy, and attach is that much faster than a backup and restore.
nice article... I like the comment of "articles I write will focus on the 'command line' (namely Query Analyser) to provide DBA’s with a reference point to turn back to when the GUI is not available for whatever reason."
I'm old enuff to remember when this was Sybase, and it was ALL command line
What am I missing here???
I don't see that these techniques as good a simple backup and restore which has no downtime?
Where is the evidence that they are any faster?
