February 10, 2011 at 9:05 am
Markus (2/10/2011)
I still say a new version of SQL Server every three years is too quick.. but that is just me.... and the software company had not certified Win2008\SQL2008 yet so we installed two clustered Win2003/SQL2005 clusters for it.... jeesh huh?
:w00t: !!! You finally get the OK to upgrade SQL Server too only find out that the rest of the software apps can't do it yet! MS is already at SQL 2008 R2. We keep prolonging the pain of upgrading, waiting for that lowest common denominator between software apps, operating systems and hardware to be just right and worth it.
February 10, 2011 at 9:26 am
DavidL (2/10/2011)
We're one of those places still running 6.5, as well as 2005 and 2008. About 6 years ago we moved it (6.5) to a virtual machine, because finding hardware that could run NT was getting hard, and keeping many spares on the shelf was not working (they tend to degrade, interestingly enough). It is running a mission critical application (a factory automation system) that we 'could' upgrade to the latest version (which would then require sql server 2005, I think). However, the upgrade project has enormous implications to the operation of our plant, and if something isn't broke, why fix it? We will probably be using it for about another 5 years, and then will upgrade only because our plant will have outgrown the capacity of the plc's -- NOT the capabilities of 6.5 -- and when they need to be upgraded we will just opt for a new automation system.
I have a pretty long history in transportation (truck and rail) and what I'm about to say is based on that experience. If the analogy is weak, then ignore me 🙂
In transportation and other industries, the most successful companies generally take scheduled maintenance and replacement of critical equipment very seriously. That means everything from greasing bearings on a precise schedule, to sending out oil samples to determine the most cost-effective time to change oil. And those just scratch the surface of the effort and analysis.
I would argue that having to run SQL Server 6.5 on a virtual machine because you can't find hardware to properly support the OS requirements is actually pretty solid evidence that something is broken. That strikes me as being no different than a police force using cars of that era in their main fleet. There is nothing wrong with keeping old stuff around for curiosity, historical, or promotional purposes, but technology that requires that level of attention to keep running should definitely not be the foundation of mission-critical operations.
February 10, 2011 at 9:27 am
To point out there are significant additional expenses when moving to newer software. Think of the cost in man hours when upgrading SQL Server - replacing all those depreciated items used through out your code.
Not only SQL Server, but lets take Microsoft office as an example, the cost of the man hours expended for retraining those familiar and adept at using say Word 2003, and the lost hours of productivity during the retraining period. All of these expenses have to be considered to measure the Return On Investment, before making the decision to purchase new software of any type by any maker.
I would rather follow the path of "If it is not broke do not fix it".
February 10, 2011 at 9:37 am
Ron Porter (2/10/2011)
DavidL (2/10/2011)
We're one of those places still running 6.5, as well as 2005 and 2008. About 6 years ago we moved it (6.5) to a virtual machine, because finding hardware that could run NT was getting hard, and keeping many spares on the shelf was not working (they tend to degrade, interestingly enough). It is running a mission critical application (a factory automation system) that we 'could' upgrade to the latest version (which would then require sql server 2005, I think). However, the upgrade project has enormous implications to the operation of our plant, and if something isn't broke, why fix it? We will probably be using it for about another 5 years, and then will upgrade only because our plant will have outgrown the capacity of the plc's -- NOT the capabilities of 6.5 -- and when they need to be upgraded we will just opt for a new automation system.I would argue that having to run SQL Server 6.5 on a virtual machine because you can't find hardware to properly support the OS requirements is actually pretty solid evidence that something is broken. That strikes me as being no different than a police force using cars of that era in their main fleet. There is nothing wrong with keeping old stuff around for curiosity, historical, or promotional purposes, but technology that requires that level of attention to keep running should definitely not be the foundation of mission-critical operations.
Hmmm. Well, I think this can get pretty 'philosophical'. We've found a very robust way to continue to use the software. Running 6.5 on a virtual machine actually requires almost no attention whatsoever -- less, I think, than the original configuration of a physical server running NT. Yet, I understand what you are saying and I would agree that in an ideal world we would not be doing this, but our company's world is not an ideal one, and there are other complicating factors. Namely, that the time and money and downtime investment in upgrading the automation software vastly outweigh the benefits of being 'correct'! There will come a time when we will have no choice but to upgrade the software, but it will be because the plant has actually outgrown that software's capabilities, which to me is the 'bestest' reason to upgrade...
February 10, 2011 at 9:41 am
george sibbald (2/10/2011)
steve, are you saying MS will not even supply you the fix for a KNOWN bug without extended support or a one off payment?
AFAIK, this is how it works. There are no more CUs, no more hotfixes from CSS, unless you have paid. I don't think they support one off payments, only Extended Agreements.
February 10, 2011 at 9:47 am
DavidL (2/10/2011)
Hmmm. Well, I think this can get pretty 'philosophical'. We've found a very robust way to continue to use the software. Running 6.5 on a virtual machine actually requires almost no attention whatsoever -- less, I think, than the original configuration of a physical server running NT. Yet, I understand what you are saying and I would agree that in an ideal world we would not be doing this, but our company's world is not an ideal one, and there are other complicating factors. Namely, that the time and money and downtime investment in upgrading the automation software vastly outweigh the benefits of being 'correct'! There will come a time when we will have no choice but to upgrade the software, but it will be because the plant has actually outgrown that software's capabilities, which to me is the 'bestest' reason to upgrade...
I know of a few friends that run v6.5 in virtual machines. Hardware is the reason, mostly because NT 4 drivers are not around, but a 1:1 VM:host is a perfect solution. They have plenty of horsepower, a DR capable system that can be moved to another box, and a working database server.
One of these is for a keycard system, the upgrade for which would cost more for the keycard software than for SQL Server, and provides no real benefits. The other is a voice mail system, and SQL provides locators to .WAV files. Again, for the company, no great benefit to spend thousands of dollars.
The truck analogy is good, but not perfect. Lots of companies do run older trucks, and maintain them according to schedule to ensure they perform well. Replacement cycles in companies can be driven by the need for parts as well as for tax reasons. Once something is depreciated, some people think it's worth replacing.
February 10, 2011 at 10:08 am
Steve Jones - SSC Editor (2/10/2011)
george sibbald (2/10/2011)
steve, are you saying MS will not even supply you the fix for a KNOWN bug without extended support or a one off payment?AFAIK, this is how it works. There are no more CUs, no more hotfixes from CSS, unless you have paid. I don't think they support one off payments, only Extended Agreements.
hmmm, thats odd, you would think if it was a known issue with their product you had hit , MS would be honour bound to supply the fix. Perhaps I am spoilt by having extended support.!
---------------------------------------------------------------------
February 10, 2011 at 10:23 am
For any old platforms that one deliberately tries to keep in service... stockpile parts and keep bare metal restore capable drive images available, or virtualize it while you still can.
It's often very difficult to impossible to rebuild a very old, unsupported system after a catastrophic failure of some sort. The "We'll just install the OS and software, then restore from backup" works very poorly when the OS and/or software doesn't work on any hardware currently available.
I know someone who is currently trying to find some old SPARCstation parts because they had chosen to continue running an old, unsupported piece of software.
February 10, 2011 at 10:31 am
Steve Jones - SSC Editor (2/10/2011)
george sibbald (2/10/2011)
steve, are you saying MS will not even supply you the fix for a KNOWN bug without extended support or a one off payment?AFAIK, this is how it works. There are no more CUs, no more hotfixes from CSS, unless you have paid. I don't think they support one off payments, only Extended Agreements.
My understanding is that the Extended Support Agreement only provides security fixes and that you have to buy a Extended HotFix Agreement if you want any non-security bug fixes after the mainstream support ends.
And here is the kicker from their Lifecycle Policy page: "Non-security hotfix support: Requires extended hotfix agreement, purchased within 90 days of mainstream support ending."
So if you want any non-security bug fixes for SQL Server 2005 you will have to purchase two extended agreements before the end of July. (You can't wait until you experience the bug in August.)
February 10, 2011 at 11:33 am
Our very latest system is on Server 2003/ SQL 2005. As a small company we run hardware and software until it's not cost effective. We can't keep up with Redmonds need for cash every upgrade cycle.
As for SQL bloggers and writers: Don't assume that we users, developers and DBAs only want to hear about the latest and greatest features of R2, VS 2010 or pre-release betas. We can't afford the new stuff, our bosses won't budget for it and it may be years before we will deploy it.
February 10, 2011 at 11:51 am
chrisn-585491 (2/10/2011)
As for SQL bloggers and writers: Don't assume that we users, developers and DBAs only want to hear about the latest and greatest features of R2, VS 2010 or pre-release betas. We can't afford the new stuff, our bosses won't budget for it and it may be years before we will deploy it.
We'll still publish SQL 2005 stuff for the rest of this year, but likely move to SQL 2008 then for most of our stuff. Course, if you send in something specifically SS2K5, we won't turn you down for that reason.
February 10, 2011 at 2:12 pm
I think a life cycle of three years is too short to be manageable.
It takes about a year before we even get the new version approved internally or before our vendors are able to provide a new release.
We decided to replace our SQL versions with an alternating process:
We had some SS2K and SS2K5 versions when we decided to replace the SS2K with SS2K8 and leave SS2K5 as it is. Now we're scheduling to replace SS2K5 with Denali by keeping SS2K8.
There are also two different migration scenarios: Either perform a "real migration" or running the DB in a lower comp mode.
Even with such a process we're constantly running at least three versions in production, if taking the comp mode into consideration. Once we're done eliminating the old versions we need to start migrating the systems we "simply" moved (= "keep-comp-mode migration").
Before we're done with migration, usually a new version is available so we need to start looking into it.
Yes, it's a permanent process. And no, we don't have dedicated staff for it...
February 10, 2011 at 2:52 pm
With older software, you also have to consider the existing skills base to support it. It's relatively easy to find a DBA who knows v2005, maybe a bit harder to find someone who knows v7/2000 and probably somewhat difficult to find someone who knows v6.5. These things don't run themselves (shock, horror!). Not just that, vendor-supported upgrade paths might only go back 1 or 2 versions. MS is better than most about this, but there is no direct path from v6.5 to v2008. At a minimum, you are looking at a partial app re-write and a significant data migration. To me, these are two big reasons why you would want to follow the vendor path - at least loosely.
James Stover, McDBA
February 10, 2011 at 3:15 pm
LutzM (2/10/2011)
We decided to replace our SQL versions with an alternating process:We had some SS2K and SS2K5 versions when we decided to replace the SS2K with SS2K8 and leave SS2K5 as it is. Now we're scheduling to replace SS2K5 with Denali by keeping SS2K8.
same here. though we won't do SS2K5 till next year at the earliest unless an app upgrade happens to come along that supports SS2k8 or above.
---------------------------------------------------------------------
February 10, 2011 at 3:46 pm
george sibbald (2/10/2011)
LutzM (2/10/2011)
We decided to replace our SQL versions with an alternating process:We had some SS2K and SS2K5 versions when we decided to replace the SS2K with SS2K8 and leave SS2K5 as it is. Now we're scheduling to replace SS2K5 with Denali by keeping SS2K8.
same here. though we won't do SS2K5 till next year at the earliest unless an app upgrade happens to come along that supports SS2k8 or above.
By "scheduling" I meant we have Denali installed on a test system evaluating what's new and what "traps" we might face (like the missing ORDER BY in views from SS2K to SS2K5). It's like an alpha-state evaluation. I don't think we start migration of production systems before the first service pack... Sounds like a similar process.
Viewing 15 posts - 16 through 30 (of 33 total)
You must be logged in to reply to this topic. Login to reply