February 4, 2009 at 8:48 am
Hi Gurus,
Does anyone know if SQL 2005 can be upgraded from 32 bit to 64 bit Enterprise edition?
This is a Windows 2003 64 bit machine running a SQL 2005 Standard SP2.
Ideally I want to upgrade from the existing Standard 32 bit edition to an Enterprise 64 bit edition, in that case is an Inplace upgrade possible if not does it have to be side-by-side.
I assume this calls for a new 64 bit install and doing a backup restore for the databases but I am not sure if the downtime would be in the permissible limits as I have 12 databases that need to be moved..
Any suggestions would be highly appreciated..
Thanks!!
The_SQL_DBA
MCTS
"Quality is never an accident; it is always the result of high intention, sincere effort, intelligent direction and skillful execution; it represents the wise choice of many alternatives."
February 4, 2009 at 9:49 am
Hey Steve..can we have something like 'BUMP' :P( bring up my post) as in facebook to make sure our valuable posts are not lost in the dungeon..
Thanks!!
The_SQL_DBA
MCTS
"Quality is never an accident; it is always the result of high intention, sincere effort, intelligent direction and skillful execution; it represents the wise choice of many alternatives."
February 4, 2009 at 9:53 am
I'm quite certain there is no direct upgrade path from x86 to x64in SQL 2005.
If backup and restore isn't an option, detach/attach should be a fair bit quicker.
February 4, 2009 at 9:56 am
Can I do an upgrade to 32 bit Enterprise and then upgrade to 64 bit Enterprise?..just firing in the air..
Thanks!!
The_SQL_DBA
MCTS
"Quality is never an accident; it is always the result of high intention, sincere effort, intelligent direction and skillful execution; it represents the wise choice of many alternatives."
February 4, 2009 at 9:59 am
Daveee (2/4/2009)
I'm quite certain there is no direct upgrade path from x86 to x64in SQL 2005.If backup and restore isn't an option, detach/attach should be a fair bit quicker.
I guess you meant detaching on the old and attaching on the new box..sounds like a good idea, but do you know how much time it would take for 12 databases with 100 GB max db size..
Just to clarify..does it mean there would be a downtime???
Thanks!!
The_SQL_DBA
MCTS
"Quality is never an accident; it is always the result of high intention, sincere effort, intelligent direction and skillful execution; it represents the wise choice of many alternatives."
February 4, 2009 at 10:16 am
The detach/attach process is very quick as you're not creating files and hitting I/O.
You could script it for minimal downtime as I find the GUI can be cumbersome if you have a lot of database files to locate.
So I'd suggest....
1. Build your SQL 2005 x64 somewhere else
2. Detach your 1st db
eg
USE master;
GO
EXEC sp_detach_db @dbname = N'AdventureWorks';
GO
3. Copy your files over to the new server
4. Have this script ready to go to attach
USE master;
GO
CREATE DATABASE MyAdventureWorks
ON (FILENAME = 'C:\MySQLServer\AdventureWorks_Data.mdf'),
(FILENAME = 'C:\MySQLServer\AdventureWorks_Log.ldf')
FOR ATTACH;
GO
5. Repeat for the other DB's
😎
February 4, 2009 at 10:16 am
It will not be long if you copy and put all your MDF LDF and NDF files in the 64bits SQL Server Data Sub folder before you go to SMS to run the attach wizard.
Kind regards,
Gift Peddie
February 4, 2009 at 10:48 am
Gift Peddie (2/4/2009)
It will not be long if you copy and put all your MDF LDF and NDF files in the 64bits SQL Server Data Sub folder before you go to SMS to run the attach wizard.
Considering the fact that we need this on production, I don't think I can copy the files while the databases are online, as the files cannot be copied.
If I were to bring the DB's offline I will have to make sure that the server had enough space to hold a copy of all the data files along with the existing files.
Sounds a goof idea to my anyways but surely calls for a downtime..need to update this in the project plan..
Well Davee and Peddie thanks a lot for the insight and do let me know if there happens to be a cleaner and affordable way to achieve this simple task..
Thanks!!
The_SQL_DBA
MCTS
"Quality is never an accident; it is always the result of high intention, sincere effort, intelligent direction and skillful execution; it represents the wise choice of many alternatives."
February 4, 2009 at 10:55 am
Sorry I didn't suggest this earlier but Transaction Log Shipping is another good option for your migration.
This might prove to be lower risk and slightly less downtime. You then have the option of failing back if things go pear shaped.
February 4, 2009 at 11:03 am
You could get those files from restored backups in your existing server. You were talking about restoring backups restore these backup in your current server with new name and copy the files added to your Data folder for each database.
Kind regards,
Gift Peddie
February 4, 2009 at 11:08 am
Daveee (2/4/2009)
Sorry I didn't suggest this earlier but Transaction Log Shipping is another good option for your migration.This might prove to be lower risk and slightly less downtime. You then have the option of failing back if things go pear shaped.
Well this is an option..may be I could do it one by one by setting up log shipping for a database at a time and move on to the next one..I will probably do some research on this one for our enivronment..
Thanks!!
The_SQL_DBA
MCTS
"Quality is never an accident; it is always the result of high intention, sincere effort, intelligent direction and skillful execution; it represents the wise choice of many alternatives."
February 4, 2009 at 11:14 am
Gift Peddie (2/4/2009)
You could get those files from restored backups in your existing server. You were talking about restoring backups restore these backup in your current server with new name and copy the files added to your Data folder for each database.
If I understand it correctly I take a most recent backup and restore it on the new server's designated folder. Only thing I need to make sure is that there is a supposed downtime while it is restored so that no changes are missed with regards to data..
If this is the only way I can upgrade from the 2005 32 bit Std to 64 bit Enterprise..I guess I will do it.
Thanks!!
The_SQL_DBA
MCTS
"Quality is never an accident; it is always the result of high intention, sincere effort, intelligent direction and skillful execution; it represents the wise choice of many alternatives."
February 4, 2009 at 11:18 am
That is not what I am saying I have been in shops you can take a backup and restore it with new name in the same server. This means your production is still running move the restored ones to the new 64bits installation. This will reduce down time and the log shipping will also work.
Kind regards,
Gift Peddie
February 4, 2009 at 11:24 am
Yes I think I planned to do it the way you mentioned above with the backup and restore.
I will work on installing Litespeed on the new server so that this process completes faster. We use Litespeed on the existing production..
Thanks again to all for the suggestions..and thanks to you too Peddie...
The_SQL_DBA
MCTS
"Quality is never an accident; it is always the result of high intention, sincere effort, intelligent direction and skillful execution; it represents the wise choice of many alternatives."
Viewing 14 posts - 1 through 13 (of 13 total)
You must be logged in to reply to this topic. Login to reply