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


Migration Doubt


Migration Doubt

Author
Message
misanthrope13
misanthrope13
SSC-Enthusiastic
SSC-Enthusiastic (160 reputation)SSC-Enthusiastic (160 reputation)SSC-Enthusiastic (160 reputation)SSC-Enthusiastic (160 reputation)SSC-Enthusiastic (160 reputation)SSC-Enthusiastic (160 reputation)SSC-Enthusiastic (160 reputation)SSC-Enthusiastic (160 reputation)

Group: General Forum Members
Points: 160 Visits: 163
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
Lynn Pettis
Lynn Pettis
SSC Guru
SSC Guru (94K reputation)SSC Guru (94K reputation)SSC Guru (94K reputation)SSC Guru (94K reputation)SSC Guru (94K reputation)SSC Guru (94K reputation)SSC Guru (94K reputation)SSC Guru (94K reputation)

Group: General Forum Members
Points: 94677 Visits: 38956
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.

Cool
Lynn Pettis

For better assistance in answering your questions, click here
For tips to get better help with Performance Problems, click here
For Running Totals and its variations, click here or when working with partitioned tables
For more about Tally Tables, click here
For more about Cross Tabs and Pivots, click here and here
Managing Transaction Logs

SQL Musings from the Desert Fountain Valley SQL (My Mirror Blog)
SQLRNNR
SQLRNNR
SSC Guru
SSC Guru (66K reputation)SSC Guru (66K reputation)SSC Guru (66K reputation)SSC Guru (66K reputation)SSC Guru (66K reputation)SSC Guru (66K reputation)SSC Guru (66K reputation)SSC Guru (66K reputation)

Group: General Forum Members
Points: 66523 Visits: 18570
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

Ed Wagner
Ed Wagner
SSC-Forever
SSC-Forever (48K reputation)SSC-Forever (48K reputation)SSC-Forever (48K reputation)SSC-Forever (48K reputation)SSC-Forever (48K reputation)SSC-Forever (48K reputation)SSC-Forever (48K reputation)SSC-Forever (48K reputation)

Group: General Forum Members
Points: 48653 Visits: 10844
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.


Tally Tables - Performance Personified
String Splitting with True Performance
Best practices on how to ask questions
Lynn Pettis
Lynn Pettis
SSC Guru
SSC Guru (94K reputation)SSC Guru (94K reputation)SSC Guru (94K reputation)SSC Guru (94K reputation)SSC Guru (94K reputation)SSC Guru (94K reputation)SSC Guru (94K reputation)SSC Guru (94K reputation)

Group: General Forum Members
Points: 94677 Visits: 38956
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.

Cool
Lynn Pettis

For better assistance in answering your questions, click here
For tips to get better help with Performance Problems, click here
For Running Totals and its variations, click here or when working with partitioned tables
For more about Tally Tables, click here
For more about Cross Tabs and Pivots, click here and here
Managing Transaction Logs

SQL Musings from the Desert Fountain Valley SQL (My Mirror Blog)
SQLRNNR
SQLRNNR
SSC Guru
SSC Guru (66K reputation)SSC Guru (66K reputation)SSC Guru (66K reputation)SSC Guru (66K reputation)SSC Guru (66K reputation)SSC Guru (66K reputation)SSC Guru (66K reputation)SSC Guru (66K reputation)

Group: General Forum Members
Points: 66523 Visits: 18570
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

Grant Fritchey
Grant Fritchey
SSC Guru
SSC Guru (98K reputation)SSC Guru (98K reputation)SSC Guru (98K reputation)SSC Guru (98K reputation)SSC Guru (98K reputation)SSC Guru (98K reputation)SSC Guru (98K reputation)SSC Guru (98K reputation)

Group: General Forum Members
Points: 98291 Visits: 33014
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

The Scary DBA
Author of: SQL Server Query Performance Tuning and SQL Server Execution Plans
Product Evangelist for Red Gate Software
misanthrope13
misanthrope13
SSC-Enthusiastic
SSC-Enthusiastic (160 reputation)SSC-Enthusiastic (160 reputation)SSC-Enthusiastic (160 reputation)SSC-Enthusiastic (160 reputation)SSC-Enthusiastic (160 reputation)SSC-Enthusiastic (160 reputation)SSC-Enthusiastic (160 reputation)SSC-Enthusiastic (160 reputation)

Group: General Forum Members
Points: 160 Visits: 163
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.
quackhandle1975
quackhandle1975
SSCarpal Tunnel
SSCarpal Tunnel (4.2K reputation)SSCarpal Tunnel (4.2K reputation)SSCarpal Tunnel (4.2K reputation)SSCarpal Tunnel (4.2K reputation)SSCarpal Tunnel (4.2K reputation)SSCarpal Tunnel (4.2K reputation)SSCarpal Tunnel (4.2K reputation)SSCarpal Tunnel (4.2K reputation)

Group: General Forum Members
Points: 4212 Visits: 1242
TEST-TEST-TEST!!! :-D

(Sorry for obvious-post-of-the-week, but OP did not mention if he had any test or Pre-prod systems/instances)

qh

Who looks outside, dreams; who looks inside, awakes. – Carl Jung.
homebrew01
homebrew01
SSChampion
SSChampion (12K reputation)SSChampion (12K reputation)SSChampion (12K reputation)SSChampion (12K reputation)SSChampion (12K reputation)SSChampion (12K reputation)SSChampion (12K reputation)SSChampion (12K reputation)

Group: General Forum Members
Points: 12342 Visits: 9222
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.



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