April 29, 2010 at 12:20 pm
Don't beat up on me, but we still run SQL2K on Win Server 2003. It pretty well meets our needs and it's been easier just not to ever update.
As part of a major server purchase (major for us that is -- probably 3 servers), we'll get Win Server 2008 R2 (probably Datacenter Edition) using a shared storage array. So will our SQL2K (Standard Edition) run on it? Or will we need to update SQL now?
(I know there's quite often a difference between "officially supported" and "it will work" so I'm thinking maybe that exists in this case.)
I found this reference http://msdn.microsoft.com/en-us/library/aa176565(SQL.80).aspx but it predates Win Server 2008 so it can't answer the question.
Thanks for any answer. We're having a meeting this afternoon so quick info, even if incomplete, will be appreciated even if I have to wait longer for definitive info.
April 29, 2010 at 2:29 pm
Never mind - in the meeting the boss decided to update to SQL 2008.
April 29, 2010 at 3:14 pm
wodom (4/29/2010)
Never mind - in the meeting the boss decided to update to SQL 2008.
That is a better choice.
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
April 30, 2010 at 6:20 am
Better choice indeed. SQL 2k8 gives you so many more options that 2k. But you will have a LOT of code & stuff to upgrade, so get ready to work hard.
April 30, 2010 at 6:33 am
Actually, the amount of T-SQL to update will depend greatly on how close the development team followed best practices. My organization recently upgraded from SQL 2000 to SQL 2008 with literally less than 10 code changes on a database of over 5,000 objects. The database has been operating without any problems for roughly a month now.
I would recommend running the SQL Upgrade Advisor to give you some idea of the impact on your situation in regard to length of time. From my past experience, ANSI-style JOINs, if you have them, are the most common problem to fix, as they are not supported in 2008.
SQL Server 2008 Upgrade Advisor can be found here:
Good luck!
April 30, 2010 at 10:31 am
Great advice from Nabidavid.
Good practices in coding seem to dramatically reduce a lot of maintenance and upgrade work.
Use of the Upgrade advisor will help you in your planning for the upgrade.
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
May 3, 2010 at 1:26 pm
Brandie Tarvin (4/30/2010)
But you will have a LOT of code & stuff to upgrade, so get ready to work hard.
I hope not. The only real reason we're upgrading is to get high availability due to a hardware server crash last week (disk controller), that resulted in 11 hours of downtime, about 4 of which were due to the master database being corrupted. We could "sort of" afford that kind of downtime in the past, but not any more -- not in the daytime anyway. Fortunately (unless you count lost sleep) this one was all at night.
Most of the actual SQL code is generated & issued by a 3rd party application, and it would be impractical or impossible to change most of it. Most of that is inserts and updates, with some reporting.
Most of the reporting functions we wrote ourselves, but mostly it was other people so I don't know what kind of joins are prevalent. I suppose we might have to ultimately stick with a previous version of SQL. (But I still don't know if those versions will run on Win 2008 R2.)
I looked at the Advisor download page, but it doesn't go into details about how it gathers data. Is it a static inspection of the DB and the code stored therein, or does it watch the real-time SQL statement flow a la the Profiler? Most of our reporting queries are sent by external code in MS Access and Visual Basic.
May 3, 2010 at 1:43 pm
nabidavid (4/30/2010)
From my past experience, ANSI-style JOINs, if you have them, are the most common problem to fix, as they are not supported in 2008.
After reading a couple of articles, I presume you meant to say NON ANSI-style JOINs are not supported.
May 3, 2010 at 2:50 pm
Yes, you are correct. I meant Non-Ansi style joins. 😉
In the recent upgrade at our organization, we actually had a few of these JOINs. A few years ago, with a 2000 to 2005 upgrade, I ran into the same problem as well. Like your situation, the databases were actually designed by third-parties.
In the recent upgrade to 2K8, we did experience a few more minor problems which were discovered during testing that the Upgrade Advisor did not detect. However, these few problems were handled within a day or two. Just wanted to send the friendly reminder to thoroughly test beforehand.
May 3, 2010 at 2:55 pm
I looked at the Advisor download page, but it doesn't go into details about how it gathers data. Is it a static inspection of the DB and the code stored therein, or does it watch the real-time SQL statement flow a la the Profiler? Most of our reporting queries are sent by external code in MS Access and Visual Basic.
Actually, you can run your own profiler trace which can be imported into the Upgrade Advisor. However, the Upgrade Advisor does not run the trace for you.
May 4, 2010 at 8:35 am
You didn't mention 32 or 64 bit. That might also have some impact. There are things you can do on 32 bit that are not available on 64 bit.
I think W2008 R2 is 64 bit only.
Greg E
May 4, 2010 at 9:33 am
OK, thanks. Because migrating to this new server & storage hardware is a really high priority, considering the possible incompatibilities we might just want to run the current version on it, until we can test SQL 2008. But that still leaves the original question: Can SQL 2000 run on Windows Server 2008 R2 in the meantime?
May 4, 2010 at 9:43 am
Greg Edwards-268690 (5/4/2010)
You didn't mention 32 or 64 bit. That might also have some impact. There are things you can do on 32 bit that are not available on 64 bit.I think W2008 R2 is 64 bit only.
Greg E
Oops, didn't see your post before I replied to the one before it. Yes the new servers will be 64 bit, and you're probably correct that W2008 R2 is 64 bit only. We need 64 bits so we can have lots of memory for the virtualization we want to do.
What kind of things aren't available on 64 bit? You mean SQL features?
Are you saying there's a separate 64-bit version of the SQL 2008, like there will be a separate 64-bit MS Office 2010, and that version is lacking something? Or are you saying SQL just has a 32-bit version but something about it doesn't work on a 64-bit OS?
May 4, 2010 at 11:07 am
He's asking if your SQL 2000 is 64 bit or 32 bit.
I don't have experience with that version of Windows, but I think I heard that running 32 bit SQL is difficult or impossible at best.
May 4, 2010 at 11:51 am
wodom (5/4/2010)
Greg Edwards-268690 (5/4/2010)
You didn't mention 32 or 64 bit. That might also have some impact. There are things you can do on 32 bit that are not available on 64 bit.I think W2008 R2 is 64 bit only.
Greg E
Oops, didn't see your post before I replied to the one before it. Yes the new servers will be 64 bit, and you're probably correct that W2008 R2 is 64 bit only. We need 64 bits so we can have lots of memory for the virtualization we want to do.
What kind of things aren't available on 64 bit? You mean SQL features?
Are you saying there's a separate 64-bit version of the SQL 2008, like there will be a separate 64-bit MS Office 2010, and that version is lacking something? Or are you saying SQL just has a 32-bit version but something about it doesn't work on a 64-bit OS?
Drivers can have both 64 and 32 bit versions. And I seem to recall Jet driver for Access is missing - never use this, so doesn't matter to me.
Memory - yes you can address lots more natively, but you also need to set some things properly - lock pages in memory comes to mind.
You should be able to compare versions on the microsoft site and see some of the common ones.
You can run either 32 bit or a 64 bit version of SQL Server, but there is no upgrade from 32 bit to 64 bit. You have to reinstall. And your license cost is the same for either version.
I recommend that you match a dev environment for OS and SQL - same version, same bit level, for testing / development. I've had good luck with Hyper V doing this. Keeps the surprise level down to a minimum when promoting things.
It's quite an upgrade from 2000 to 2008. Although 32 and 64 bit are pretty similar in functionality, I didn't want you to assume they are exactly the same.
We went live as soon as SQL 2005 was released, on x64 bit W2003 OS. It was new enough at that time that it was almost a year before we could get the HBA to hook up to the SAN. Things are much better now. 😛
I assume that you are getting new hardware too?
Make sure someone understands the upgrade path. Just because you may have lots of memory slots, doesn't mean you can use them all effectively. There can be dependencies on filled processor sockets, and what banks are filled with what speed of RAM.
Greg E
Viewing 15 posts - 1 through 15 (of 34 total)
You must be logged in to reply to this topic. Login to reply