Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase 12»»

Migration Doubt Expand / Collapse
Author
Message
Posted Thursday, July 31, 2014 10:18 AM
SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC Rookie

Group: General Forum Members
Last Login: 2 days ago @ 8:57 AM
Points: 26, Visits: 75
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
Post #1598361
Posted Thursday, July 31, 2014 11:02 AM


SSC-Insane

SSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-Insane

Group: General Forum Members
Last Login: Today @ 8:01 AM
Points: 20,877, Visits: 32,920
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.



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)
Post #1598391
Posted Thursday, July 31, 2014 11:03 AM


SSCoach

SSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoach

Group: General Forum Members
Last Login: Tuesday, December 23, 2014 3:32 PM
Points: 18,068, Visits: 16,111
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
Post #1598392
Posted Thursday, July 31, 2014 11:42 AM
SSCarpal Tunnel

SSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal Tunnel

Group: General Forum Members
Last Login: Tuesday, December 23, 2014 11:36 AM
Points: 4,625, Visits: 4,085
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
Post #1598413
Posted Thursday, July 31, 2014 11:53 AM


SSC-Insane

SSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-Insane

Group: General Forum Members
Last Login: Today @ 8:01 AM
Points: 20,877, Visits: 32,920
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.



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)
Post #1598418
Posted Thursday, July 31, 2014 12:10 PM


SSCoach

SSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoach

Group: General Forum Members
Last Login: Tuesday, December 23, 2014 3:32 PM
Points: 18,068, Visits: 16,111
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
Post #1598426
Posted Thursday, July 31, 2014 12:14 PM


SSChampion

SSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampion

Group: General Forum Members
Last Login: Monday, December 22, 2014 3:26 AM
Points: 14,205, Visits: 28,536
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
Post #1598427
Posted Friday, August 1, 2014 8:58 AM
SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC Rookie

Group: General Forum Members
Last Login: 2 days ago @ 8:57 AM
Points: 26, Visits: 75
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.
Post #1598726
Posted Monday, August 4, 2014 3:22 AM


SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Tuesday, December 23, 2014 7:12 AM
Points: 2,462, Visits: 1,067
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


SQL 2K acts like a spoilt child - you need to coax it round with lollipops.
Post #1599167
Posted Monday, August 4, 2014 2:44 PM


SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Thursday, December 11, 2014 6:43 PM
Points: 2,838, Visits: 8,570
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.



Post #1599405
« Prev Topic | Next Topic »

Add to briefcase 12»»

Permissions Expand / Collapse