SQL 2000 std to SQL 2k5 std x64 (inplace upgrade) MS GP look here too.
-
Hope this is the right spot for this question.
I'll start with some background. We run Great Plains from Microsoft. If you've heard of Dynamics from Microsofts Biz Solutions it's one of em'
Anyway we (I) have been getting ready to upgrade from GP 7.5 running on an older sql 2000 sp4 system to the new version 9.0 My hope is to get to 2005 as soon as possible. The upgrade path kinda goes like this:
Install fresh OS and same SQL on new hardware. Copy databases or restore from a backup onto new box. Run some scripts from the old box to deal with logins. Databse owner being some group user called DYNAGROUP and a few other items relating to DB num. Then install the new GP 9.0 client and server apps and allow it to upgrade the data within the SQL server. Then you can upgrade SQL server after it's proven to be working.
Here's where my question comes in. I would like to install a new OS with Windows 2003 std R2 x64 edition and start with SQL 2000 sp4 and then do an inplace upgrade on SQL to SQL 2005 std x64. Has anybody done that? Comments? Ideas?
Mainly I just want to do this so I can use more RAM. I have an IBM 3650 with 6gb of RAM and room for a whole lot more. I'm sure it's cheaper then running 32-bit enterprise and from my understanding that's not all that better from a memory standpoint because it's still a page file swap except it's all done in memory. (>4gb)
I would also love to hear more from users of GP and what kind of setups they have. Last year I was at Convergence and MS wasn't too helpfull in recommending doing anything special.
Thanks in advance,
Sean~
-
Sean,
a inplace upgrade from a 32-bit Edition to a 64-bit edition is not possible. You need to install a new instance and when copy your databases, logins, jobs etc. to the new instance.
Markus
[font="Verdana"]Markus Bohse[/font]
-
Ok so I could install a new instance say 32bit was GP and then install an instance of SQL x64 as GP64 Then just move the logins with a script and the agent jobs also and the databases like I did before... ?
Anybody have any issues running SQL 2000 std on WIN 2003 std x64?
-
?? nobody ??
-
Sean,
I haven't used 64-bit standard edition only Enterprise Edit.
We had no issues running it side by side with 32-bit SQL 2000, but I remember one issue with linked servers from 64-bit to 32-bit. But there's a fix in SP4 for sql 2000 if you need it. Otherwise your strategie sounds ok.
One thing you need to check if GP accepts a named instance. I know that some MS application require a default instance in order to work. I found workarounds for most cases, like editing config files and using server aliases, but it can be quite frustrating.
Hope this helps
Markus
[font="Verdana"]Markus Bohse[/font]
-
Hi, We are running SQL2K5 x64 on X64 bit processors with Win2K3 x64. This takes full advantage of the 64bit processing. Wouldn't putting a X64 bit app on a X32bit process just be not utilizing the app to it's best possible usage? Is it compatable or could you be setting yourself up for issues later on?
-
I assume you mean putting a 32-bit app (sql 2000) on a 64-bit process (2k3x64) right? Well here's what I've been told. Right or wrong.
Because I'm on gp 7.5 and SQL 2000 and want to upgrade I can't just put the data on SQL 2005.. So I have to start with SQL 2000. Here's what I've been doing.
I have a production server that is running SQL 2000 sp4 std on Windows 2000. I want to retire this. I've got a new test box and a new Production server.
The test box is an IBM x346 3gig xeon (non-dual core) the Production box is a x3650 with a E5160 cpu and currently 6gb of RAM.
Now If you running W Server 2k3 x64 you can use a lot of RAM...16-32GB something like that. Using 1gb chips I can easily put 12 to 14gb into the x3650 I own. (under $2k) Now SQL 2005 x32 can use 4gb per INSTANCE of RAM. But SQL 2005 x64 could use all free RAM I'm told. Okay, so I don't want to run on 32-bit SQL for long.. just long enough to do the upgrade from 7.5 to 9.0 in Great plains. So what does that mean exactly? Well I'm not sure.. but I watched an upgrade yesterday on my test server (x346) It took 1 hour 55 mins to upgrade 3 databases. Dynamics *2gb* Ferris *4.2*gb (our main company data) and Pharm *2gb* our sub company data. It seems to be removing and replacing everything. Stored procedures, tables in a few cases, objects, views, gets rid of the logs and makes newones. It's doing a lot of crap and the CPU gets used. hovers in the 20% to 60% and spikes to 89+% often. Page file usage was at 1.9gb and the 15k diks were spinning like a mother.
Basicly it's nice to see your hardware get really used.Well I'm still told that you can't upgrade the data from 7.5 to 9.0 using SQL 2005 and nobody has a clue about 2005 x64. Look from my point of view why would it matter? It should just work right?
But that's why I'm asking about 32 on x64.
Thanks,
Sean~
-
Thanks about the Enterprise info.. Not much diffrence between them so that's good news.
As to the fix you mean SP4 makes the issue a non-issue right? So no hot-fix necessary right?
Well GP 9.0 does... I checked out 7.5 before and I was able to get a client to access the 7.5 data using a ODCB named instance. SO that's good to know. Yes GP was installed as default on the production server we use now. But I feel that's messy. And every once in a while you come accross some crap that needs to be default or it don't work. So I always try and use a named instance 1st. SO a new app has room to work in need be.
Thanks agian for the info.
SEan~
-
Ok now I understand the issue better. What I am doing in my corporate enviornment is I have three SQL2005 boxes setup. Two Prod boxes are X64 and the test box is X32. The databases we are working on moving are coming from various SQL2000 systems. First step is to run the sql2005 upgrade advisor against the projected database for upgrades. This helps identify anything that needs to be worked on to prep for the move. Once the developers have solved any identified issues the database is copied to the test system. This is done by detaching the database and moving the mdf and ldf files and attaching them in the test enviornment. All process that are used against the prod database are tested against the test eviornment and any modifications done to test are then put to the original prod database.
Once the database testing is done the production database is again detached and the mdf and ldf are moved to the new prod X64 SQL2005 machines and the database is attached there. I have so far moved 12 databases from other systems using this method with out any problems. All of these databases are also replicated to the 2nd machine but that is another discussion. I have had no problems with the physical moving of the databases, and for the most part the developers also are not running into too many issues other than some minor changes. (We required PK's to be put into all of the tables if they were non-existant for replication)
We have not done this with a 7.5 and when we have to do this we will first move it to 2000. One of our current databases that is in the move is being reengineered right now to go to 2000 from 7(it needed it anyway).Then it will be moved to the 2005 system.
Does this help?
-
I forgot to add that I have also done restores from backups from the earlier versions to onto this new box.
-
Yes thank you...
Viewing 11 posts - 1 through 10 (of 10 total)
You must be logged in to reply to this topic. Login to reply