Risks of not upgrading from SQL 2000, SQL 2005

  • Hello - I am inheriting 5 servers to administer from a jack-of-all-trades DBA/developer in another department.

    2 of the instances are SQL 2000 standard and are worried that SQL 2000 is out of support.

    The jack-of-all-trades DBA/developer will still be involved but has no desire to upgrade the SQL 2000 instances. (DTS packages that would need to be rewritten and he is understaffed. Plus, its not broke so don't fix it.)

    I was told by my boss that we need to inform them of the risks of running an out of support version.

    I had a conversation with the developer and he said "if the servers are behind a firewall, then there are no security risks"

    Can anyone offer an educated response to the firewall statement? Any links or insights would be appreciated.

    Thanks

    Dave

  • NJDave (5/28/2013)


    Hello - I am inheriting 5 servers to administer from a jack-of-all-trades DBA/developer in another department.

    2 of the instances are SQL 2000 standard and are worried that SQL 2000 is out of support.

    The jack-of-all-trades DBA/developer will still be involved but has no desire to upgrade the SQL 2000 instances. (DTS packages that would need to be rewritten and he is understaffed. Plus, its not broke so don't fix it.)

    I was told by my boss that we need to inform them of the risks of running an out of support version.

    I had a conversation with the developer and he said "if the servers are behind a firewall, then there are no security risks"

    Can anyone offer an educated response to the firewall statement? Any links or insights would be appreciated.

    Thanks

    Dave

    ROFLMAO. Can I borrow Jeff Moden's pork chop launcher??? That is one of the most ridiculous things I have heard in a long time. That is like saying that "I have an anti-virus program installed so there is no chance of a virus".

    Yes a firewall is a very important piece of protecting yourself but it is not enough to make such a blanket statement. Even with a properly configured firewall things like sql injection are still possible. This jack-of-all sounds like a complete cowboy. My guess is this person consistently gets it done. The problem with this type of person is they get it done right now, even if it isn't right.

    http://msdn.microsoft.com/en-us/library/ms144228.aspx

    _______________________________________________________________

    Need help? Help us help you.

    Read the article at http://www.sqlservercentral.com/articles/Best+Practices/61537/ for best practices on asking questions.

    Need to split a string? Try Jeff Modens splitter http://www.sqlservercentral.com/articles/Tally+Table/72993/.

    Cross Tabs and Pivots, Part 1 – Converting Rows to Columns - http://www.sqlservercentral.com/articles/T-SQL/63681/
    Cross Tabs and Pivots, Part 2 - Dynamic Cross Tabs - http://www.sqlservercentral.com/articles/Crosstab/65048/
    Understanding and Using APPLY (Part 1) - http://www.sqlservercentral.com/articles/APPLY/69953/
    Understanding and Using APPLY (Part 2) - http://www.sqlservercentral.com/articles/APPLY/69954/

  • There's a pretty good chance if you keep copies of your operating system installation and SQL Server installation, that you can keep those databases propped up and running for years with no issues. I worked for a company that actually had an ancient 1970s operating system running inside of a VM to keep software going as recently as 2011.

    But, if you're not very careful about making sure that you have both the OS and SQL Server installation, the first time you hit a glitch with hardware or anything else, it's possible everything will just go away... forever. I would also be very, very thorough about making sure I have good backups in place of the database itself.

    That's the best ways to mitigate the risks. Now, the biggest risk is, when your computer fails (and they do) new hardware may not work with your old operating system. It's also possible you can't get a VM to operate within a newer system. Yeah, viruses are a threat, but not a huge one only because it's unlikely that anyone is developing new viruses for such an old system.

    Your primary concern is change. Any change. As soon as you modify something that stops the process from working as it's currently configured, you may hit an issue. This can be little stuff like updating how the system logs into the network, the NIC card, disks, your SAN... anything.

    But, wall it off carefully, and yeah, you can keep it afloat for quite a while.

    "The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
    - Theodore Roosevelt

    Author of:
    SQL Server Execution Plans
    SQL Server Query Performance Tuning

  • The firewall comment is simply hilarious. Anyone who actually believes that doesn't really know how servers work. Web servers are on the internet to serve out pages. The web server communicates with the database server. If this were simple, safe and secure out-of-the-box, there would be no such thing as security patches.

    I had a situation similar to yours several years ago where we had a desktop computer impersonating a server in the data center dialing a phone number on a modem, connecting with XMODEM and sending data. Nobody wanted to touch it because there were so many little nuances and idiosyncrasies with it and we were all afraid of breaking something.

    You can keep it limping along for a long time, but as Grant pointed out, hardware does fail. Once that happens, you're going to have a very difficult time finding replacement parts and if you do, they're going to be very expensive. As an example, try buying 32 MB of EDO RAM.

    This is just an unpleasant situation to be in. If you migrate it successfully with no glitches, you haven't accomplished anything because "it works the way it always has." If you encounter a simple glitch, "you've had downtime." If you have a disaster, "you broke it." If you do nothing and it fails, "you should have seen it coming."

    If it's a possibility, I would try to work on migrating it to a current test environment. If the time comes when you get approval from the boss because he understands the risk, you'll have a jump on understanding your scope of work.

  • "It's also possible you can't get a VM to operate within a newer system"

    Can you explain this sentence more?

    These servers are currently virtualized - how would it make a difference if I was running SQL 2000? Also, why would it matter if the OS was old. Aren't you able to take a VM and move it anywhere?

    I feel like I'm misunderstanding this part.

    Also, is there documentation on how later versions have improved handling SQL injection and remote code access?

    Thanks

    Dave

  • NJDave (5/28/2013)


    "It's also possible you can't get a VM to operate within a newer system"

    Can you explain this sentence more?

    These servers are currently virtualized - how would it make a difference if I was running SQL 2000? Also, why would it matter if the OS was old. Aren't you able to take a VM and move it anywhere?

    I feel like I'm misunderstanding this part.

    Also, is there documentation on how later versions have improved handling SQL injection and remote code access?

    Thanks

    Dave

    Just that old software may require a special VM. You may not be able to run XP forever on the latest copy of HyperV or whatever. We ran into those problems trying to get the VM to work for that old 70s software. It can take some juggling. You're not there yet, but you could be someday.

    "The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
    - Theodore Roosevelt

    Author of:
    SQL Server Execution Plans
    SQL Server Query Performance Tuning

  • Thank you for explaining - I don't have VM experience yet.

    With these posts I'm able to see the potential risks of continuing to run SQL2K, but what are the current risks - does SQL 2008 do a better job protecting against SQL injection and remote code access?

    The only arguement I have for this cowboy DBA of having to get off of SQL 2000 is if his data contains PII data, then he would need encryption at rest which means SQL 2008 Enterprise is needed. Other than that, I have the threat of the VM not supporting.

    As you can imagine, when it comes to debating, this guy is a master. If you can think of other current threats of running SQL 2000 and not upgrading, please let me know. My boss asked me to explain the current and potential threats of staying with SQL 2000.

    Thanks again

    Dave

  • I wouldn't say there are new threats beyond what we've outlined here. SQL Server 2000 is good, as far as it goes. It's just grossly inadequate on a million levels, data types, recoverability, high availability, programming. I mean, it's just a different world in 2012 or even 2008R2. It's really not an easy comparison so much has improved. No, I'd say the primary risk is complete failure of the system due to being out of date. But, from what you keep asking, you seem really concerned with security. The thing to do would be to search MSDN for enhancements and fixes in that area.

    "The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
    - Theodore Roosevelt

    Author of:
    SQL Server Execution Plans
    SQL Server Query Performance Tuning

  • The risk of extended downtime grows with the age of the software.

    1) The more changes you put on your VM host the greater the risk of an old guest failing.

    2) New software risks appear each day. Your old software will probably not get patches to tackle them.

    3) The older your software, the fewer people there are who understand it and would be willing or able to fix it.

    Your business should put a value on the cost of 1 day downtime, and the cost for each additional day downtime. It should expect to have at least one day unplanned downtime each year. Just like with the 2008 financial crash, if it does not go down for 5 years running, expect a lot of downtime when it does finally go down.

    If the costs of downtime are minimal, some businesses choose to run old software until the host fails, and then leave it down. If the costs are substantial, you need to move the applications it hosts on to new software.

    Original author: https://github.com/SQL-FineBuild/Common/wiki/ 1-click install and best practice configuration of SQL Server 2019, 2017 2016, 2014, 2012, 2008 R2, 2008 and 2005.

    When I give food to the poor they call me a saint. When I ask why they are poor they call me a communist - Archbishop Hélder Câmara

Viewing 9 posts - 1 through 8 (of 8 total)

You must be logged in to reply to this topic. Login to reply