March 9, 2012 at 8:22 am
We still have SQL 2000 for one application that the vendor is still saying they are not yet ready to support a later version of SQL. This vendor has alway been slow to provide updates and are not even ready to give an estimate as to when they might support a more current version of SQL.
Francis
March 9, 2012 at 8:43 am
Not exactly the question, but we're still running 6.5! It is the core of the system that runs our plant, and the upside of upgrading is insignificant compared to the possible consequences.
March 9, 2012 at 8:54 am
Nadrek (3/9/2012)
It's more that people think SQL Server 2000 is an unsupported database software that hasn't really had patches come out (including security patches) in quite some time, and is almost certainly running on an unsupported operating system that hasn't really had patches come out (including security patches) in quite some time _and_ probably either cannot be installed on modern hardware or is difficult/finicky to install on modern hardware... and is almost certainly running on hardware that hasn't been made for a long time, for which spare parts may or may not exist anymore, and which is likely unsupported as well.My questions for those running SQL 2000 still are:
1) If you have security auditors, what do you tell them about your security environment (I did see one VPN-only access environment)
2) How do you plan on recovering from a total system failure?
2a) Have you put, or considered putting, your SQL 2000 instance on a virtual machine, to help isolate it from the (probably old) hardware?
2b) Is your SQL 2000 media still good? Do you have any kind of error correction* data for it to even detect, much less correct, bit rot or other damage to the files/media? How often do you check it?
Can't completely answer all, but a few things. SQL 2K has been out of support, but MS has still dropped some patches. Not sure of the latest one, but here's on in 2008 (http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=11919). I think security patches are still coming for SP4.
1. Auditors are all over the board. Unfortunately, lots of times security audits aren't about being "secure", but being "secure" for this platform. Lots of exceptions for particular pieces of software when the vendor doesn't provide support.
2. It can be a struggle, but to go 2a on you, lots of people have gone P2V, even if they don't use virtualization elsewhere. We moved our keycard system in 2002, which was a v6.5 server, for this reason. DR was a major concern since we'd be trying to get NT4.0 to run on modern hardware.
2b - keep it on network drives. so many places keep copies of this around, and I'd do the same thing, probably 2-3 copies on separate servers/SANs.
March 9, 2012 at 8:56 am
and is almost certainly running on an unsupported operating system that hasn't really had patches come out (including security patches) in quite some time _and_ probably either cannot be installed on modern hardware or is difficult/finicky to install on modern hardware
Those assumptions are reasonable, but not as true as you might think.
They're on in-warrently servers for one thing, so the hardware isn't that old (though I'm not sure of the year).
You mentioned VPN, but forgot to mention the firewall rules - unless you come in from the right part of the VPN, the only thing that can get to each box is the associated web server.
The only three vectors of attack I'm aware of are an insider, the web server (which is patched within hours of patch Tuesday), or through the firewall.
The IPS may mitigate two of those, and only a handful of people are "inside enough" to be an insider.
I'm sure there's something I haven't thought of, but more than a couple certified security professionals are aware of the configuration and they haven't asked me to add anything else to the mix.
(edit to add)
BTW we do off-site DR 1+ times per year and haven't had a problem in a couple years.
(Full disclosure: we have missed our back up in 24 hrs window, but not because of the db version).
FWIW,
-Chris C.
March 9, 2012 at 9:47 am
We still run a number of systems off 2000 but are in the process of migrating most to newer versions. The challenge for us has been timing and licensing. There has definitely been the argument of "if it isn't broken, don't fix it" as well as finding the time to perform the migration and having a free server to do it on. Thankfully we are now in that process albeit, a few years late.
To it's credit, SQL 2000 has been a very stable platform and has held up better than many other legacy systems that we run. Hopefully the same will be said for SQL 2012 in 10 years.
March 9, 2012 at 9:49 am
We still have several 2K servers in production; one is strictly for reporting and will be retired after the last set of reports is removed. Unfortunately the programmer that was working on that got pulled off to another project... which has happened each time we've tried to retire this server (this is the fourth attempt since 2006).
For myself, I'm still on Toyota 1990. It's reliable, inexpensive, and has fewer points of failure.
Steph Brown
March 9, 2012 at 10:05 am
We finally finished moving off SQL 2000 at the end of 2011. I miss DTS, SSIS is just not the same.
March 9, 2012 at 10:59 am
OK, how 'bout this one - in the last 6 months, we migrated over 200 physical servers running hundreds of SQL 7 and 2000 instances to SQL 2008R2. We still have at least 5 physical boxes dozens of SQL 7 DB's and.... we still have one NT4 box running SQL 6.5 because of one application.
...oops, but now we're out of money just layed off about 20% of IT.
March 9, 2012 at 11:06 am
Five basic reasons (or excuses) that I have seen SQL 2000 still running in shops in the past:
1. Shop doesn't want to spend the money to upgrade software/hardware
2. Legacy application(s) their STILL using requires SQL 2000.
3. DTS to SSIS and Visual Studio conversion is too big of curve and scares alot of DBA's that I know. This was scary when I first did it too, but once I got used to SSIS and VS I would never go back to DTS. No way.
4. Replication changed a whole bunch over the version years and would literally have to be retooled and/or startover and this too scares DBA's that already have this working.
5. Full_text indexing has changed radically from SQL 2000-2008 and would also have to literally be relearned and redone, including the queries that use it.
All this said, I would gladly go to SQL 2008 anyway and brave the challenges. Hands down. It is such a robust product now from what it was back in the the days of SQL 2000. Being scared, or not wanting to spend the money is more of an excuse nowadays than it is a reason to not upgrade. Come on, jump on in, the water is only cold at first.. 😀
"Technology is a weird thing. It brings you great gifts with one hand, and it stabs you in the back with the other. ...:-D"
March 9, 2012 at 11:17 am
About four years ago, I was involved in a project to migrate several SQL Server 2000 databases to 2005. One of the 2000 servers hosted a database containing transactional records inserted by a 3rd party IVR (interactive voice response) system. The problem is that the IVR application did not interface with SQL Server 2005; something about the provider library they were using, and the vendor was not planning to upgrade the application.
The application interfaced with only 2 stored procedures, one to lookup the caller supplied ID, and another procedure that inserted the customers response to questions. So, here is what I did:
I copied the database from 2000 to new 2005 instance on the same server, and then replaced the T-SQL code in two stored procedures in 2000 with a remote procedure call to the 2005 instance. The IVR application would make a call to 2000, which would then make the same call remotely to 2005. So, the 2000 instance was still left running, but it did nothing going forward but hand off procedure calls to the 2005 instancecontaining all the production data.
It can fine that way for another two or three years, and I think they've since switched to another vendor's application.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
March 9, 2012 at 11:25 am
Still using SQL2000, and planning to migrate to Denali/2012 this year. The primary reason we are migrating is that none of the current reporting tools/add-ons that we would like to use work with SQL2000. If they did, we would continue to use it indefinitely. We virtualized the database server 18 months ago and saw a 25%+ increase in performance from the original hardware, so from an end-user perspective, its faster than ever.
While there are several new features in Denali that are 'nice' none of them are worth the cost (and pain) of upgrading alone. If it wasn't for lack of third party vendor support, I would gladly continue to use SQL2000 indefinitely.
March 9, 2012 at 11:28 am
We have about 130 instances of SQL 2000 and even a couple of SQL 7.0.
Hardware isn't much of an issue, almost all are on VM's.
As long as it runs, I am OK with leaving them as-is until the applications are replaced.
I really don't care what any auditor might object to. I know that the company will not go for any wholesale replacement without a concrete payback, and I know they will not spend the considerable resources required to upgrade systems that are not currently causing problems.
I don't like Microsoft's policy of dropping support for older versions even if customers are willing to pay for it. They really need to grow up if they want to be the vendor of choice for enterprise systems; it's not like dropping support for an old version of Flight Simulator. I'm sure I could still take a 1990 Toyota to the dealer and get it repaired.
March 9, 2012 at 12:00 pm
I'm afraid we're going to have another polite disagreement, Travis. 🙂
TravisDBA (3/9/2012)
1. Shop doesn't want to spend the money to upgrade software/hardware
There's no reason to spend money 'fixing' something that works quite well. Upgrades are not important to a product that doesn't require the new features and is out of development.
2. Legacy application(s) their STILL using requires SQL 2000.
So, not only a DBA team but a development team would be required to perform work to upgrade an application, and the only reason to pay that would be to follow MS's release schedule? No, no. I've left software on 6.5 to avoid that very problem.
3. DTS to SSIS and Visual Studio conversion is too big of curve and scares alot of DBA's that I know. This was scary when I first did it too, but once I got used to SSIS and VS I would never go back to DTS. No way.
This can be done from a foreign server without affecting the base database design. SSIS hooks quite nicely up to SQL 2k, and is thus not a significant concern.
4. Replication changed a whole bunch over the version years and would literally have to be retooled and/or startover and this too scares DBA's that already have this working.
The majority of systems (that I'm familiar with) that are sitting on 2k boxes are standalones, not integrated projects that require replication and the like.
5. Full_text indexing has changed radically from SQL 2000-2008 and would also have to literally be relearned and redone, including the queries that use it.
This is true and it depends on how invasive your usage was throughout your structure. If something is stable and dependable, do you simply make sure the tires are full of air and the oil's full, or do you swap out the engine block which costs you money and you hope it's as good?
Being scared, or not wanting to spend the money is more of an excuse nowadays than it is a reason to not upgrade. Come on, jump on in, the water is only cold at first.. 😀
I'm afraid I consider it a perfectly valid reason. There's limited IT resources at most companies, no matter how you want to slice the cost. You can work on problem children, or you can chase Microsoft's upgrade plan for every piece of software you own. I find chasing MS to be a silly endeavour. Upgrade a software when you have reason to work on it beyond minor adjustments. I disagree with starting major overhauls just to 'stay up to date' with no other gain than saying "Yay! We're on SQL 2k8!"
Never stop learning, even if it hurts. Ego bruises are practically mandatory as you learn unless you've never risked enough to make a mistake.
For better assistance in answering your questions[/url] | Forum Netiquette
For index/tuning help, follow these directions.[/url] |Tally Tables[/url]
Twitter: @AnyWayDBA
March 9, 2012 at 12:05 pm
The reason WE are forcing the issue to upgrade is that we don't want to be caught running an unsupported version of software. 99% of the time it won't be an issue. However, what happens if a vunerability hits the wild on SQL2000... Microsoft no longer will have a fix for it.
That being said I don't know if we will retire all of our SQL2000s anyway though. Some are running applications that are either not supported by the vendor and/or the software company is out of business and we have no other way to view that historical data and no way to know if it will work on a newer version of SQL Server.
March 9, 2012 at 12:26 pm
TravisDBA (3/9/2012)
...Being scared, or not wanting to spend the money is more of an excuse nowadays than it is a reason to not upgrade. Come on, jump on in, the water is only cold at first...
"not wanting to spend the money" is not a valid reason to not upgrade?
Same could be said about not wanting to buy a new car when my old one runs fine, not buying a new iPhone because my old phone works fine, not buying a new TV because my old one works fine.
If it was your own money and someone suggested spending $80,000 to upgrade SQL Server 2000 Enterprise Edition to a new server running SQL Server 2008 R2 Enterprise Edition, even though there would be no benefit to you, how would you feel? About the same as the owners of the company where I work would feel if I suggested spending millions of dollars to produce little or no benefit?
Viewing 15 posts - 31 through 45 (of 57 total)
You must be logged in to reply to this topic. Login to reply