July 31, 2014 at 10:18 am
Greetings to all!
I'll try to make it short... I don't have much experience migrating databases (between different versions of SQL), but I've read everywhere that I have to run Upgrade Advisor, follow the tips, do a backup, restore in the new server and fix, is that right?
Well, my boss is absolutely sure it won't work well that way, because the former server was 32-bit architecture, while the new server has a 64-bit architecture (in this scenario, we're migrating from 2000 to 2008 R2), so he likes to make an entire deploy of the database on the new server via individual scripts (a huge work depending on the structure of the DB) and transfer the data later vĂa the native export tool.
I have succesfully migrated databases before with the backup/restore/fix method without any problem, even if it's from a 32-bit architecture server to a 64-bit architecture. Am I doing this wrong or do my boss have a real reason to migrate with individual scripts?
Thank you in advance
July 31, 2014 at 11:02 am
First, I would do the fixing before I do a final backup and restore.
Second, you can backup a database from a 32 bit system and restore it with no problems to a 64 bit system. The on disk structures are the same between 32 bit and 64 bit systems.
July 31, 2014 at 11:03 am
I wouldn't use the method suggested by the boss.
I will typically use one of two methods. Either in-place upgrade or side-by-side upgrade. The side-by-side allows for easier rollback.
In both cases, you can upgrade from 2000. I might even restore the database onto the 2008R2 box and leave it in compat 80 for a few weeks to test. Then switch compat to 2008R2 and continue to verify.
Jason...AKA CirqueDeSQLeil
_______________________________________________
I have given a name to my pain...MCM SQL Server, MVP
SQL RNNR
Posting Performance Based Questions - Gail Shaw[/url]
Learn Extended Events
July 31, 2014 at 11:42 am
Jason is braver than I am by upgrading in place. I've had SP installations fail, so I'm a bit wary of upgrading in-place.
When I upgrade, I do so to a new server. I use the backup/restore method to migrate the databases, usually in groups of several databases at a time. I script every backup/restore command ahead of time and test before the actual production move. This also gives developers the opportunity to test their applications while the old databases are still in production.
When it comes time to do the actual production move, you already have everything scripted and tested so there won't be any surprises.
The time to actually perform the move is used by others to point their applications to the new server.
If disaster strikes during the move, the fallback position is to keep using the original databases until the next blackout window.
July 31, 2014 at 11:53 am
Ed Wagner (7/31/2014)
Jason is braver than I am by upgrading in place. I've had SP installations fail, so I'm a bit wary of upgrading in-place.When I upgrade, I do so to a new server. I use the backup/restore method to migrate the databases, usually in groups of several databases at a time. I script every backup/restore command ahead of time and test before the actual production move. This also gives developers the opportunity to test their applications while the old databases are still in production.
When it comes time to do the actual production move, you already have everything scripted and tested so there won't be any surprises.
The time to actually perform the move is used by others to point their applications to the new server.
If disaster strikes during the move, the fallback position is to keep using the original databases until the next blackout window.
And of course, the really smart people (are they??) may also make use of DNS redirection so that applications don't have to change connection strings. Just use DNS to point to the new server with the old name. Hopefully the old name is actually generic for the application(s) and has no relation to any actual server name past, present, or future. Think about it, makes changing servers easier.
July 31, 2014 at 12:10 pm
Lynn Pettis (7/31/2014)
Ed Wagner (7/31/2014)
Jason is braver than I am by upgrading in place. I've had SP installations fail, so I'm a bit wary of upgrading in-place.When I upgrade, I do so to a new server. I use the backup/restore method to migrate the databases, usually in groups of several databases at a time. I script every backup/restore command ahead of time and test before the actual production move. This also gives developers the opportunity to test their applications while the old databases are still in production.
When it comes time to do the actual production move, you already have everything scripted and tested so there won't be any surprises.
The time to actually perform the move is used by others to point their applications to the new server.
If disaster strikes during the move, the fallback position is to keep using the original databases until the next blackout window.
And of course, the really smart people (are they??) may also make use of DNS redirection so that applications don't have to change connection strings. Just use DNS to point to the new server with the old name. Hopefully the old name is actually generic for the application(s) and has no relation to any actual server name past, present, or future. Think about it, makes changing servers easier.
That is a recommendation I typically make as well when migrating servers. Failback is much easier that way.
Jason...AKA CirqueDeSQLeil
_______________________________________________
I have given a name to my pain...MCM SQL Server, MVP
SQL RNNR
Posting Performance Based Questions - Gail Shaw[/url]
Learn Extended Events
July 31, 2014 at 12:14 pm
Another vote for the side-by-side upgrade. In place upgrades burn sometimes. I'm just not a fan.
And yes, your boss is wrong. That's not the right way to go about it at all.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
August 1, 2014 at 8:58 am
I want to thank you all for your replies, this way I can show to my boss just how wrong he is and tell him we're wasting a lot of time, thank you very much!
Lynn, in fact the way you say is how I do, first Upgrade Advisor, then fixing, then backup with fixes done, restore in the new server and change compatibility mode, though I'll do some research on side-by-side upgrade, as you and Grant have suggested.
August 4, 2014 at 3:22 am
TEST-TEST-TEST!!! đ
(Sorry for obvious-post-of-the-week, but OP did not mention if he had any test or Pre-prod systems/instances)
qh
August 4, 2014 at 2:44 pm
SQLRNNR (7/31/2014)
In both cases, you can upgrade from 2000. I might even restore the database onto the 2008R2 box and leave it in compat 80 for a few weeks to test. Then switch compat to 2008R2 and continue to verify.
I don't know if upgrade advisor will check for old left joins such a *=.
But in our case we had old SQL code in ColdFusion & PHP, so even if the database itself is 2008 compatible, make sure any external code is also compatible.
August 5, 2014 at 3:57 am
homebrew01 (8/4/2014)
SQLRNNR (7/31/2014)
In both cases, you can upgrade from 2000. I might even restore the database onto the 2008R2 box and leave it in compat 80 for a few weeks to test. Then switch compat to 2008R2 and continue to verify.
I don't know if upgrade advisor will check for old left joins such a *=.
But in our case we had old SQL code in ColdFusion & PHP, so even if the database itself is 2008 compatible, make sure any external code is also compatible.
It will check for that within the database, but not the outside code. You raise a great point.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
Viewing 11 posts - 1 through 10 (of 10 total)
You must be logged in to reply to this topic. Login to reply