October 27, 2008 at 9:20 pm
Comments posted to this topic are about the item Updating Aging Databases
Best wishes,
Phil Factor
October 27, 2008 at 10:20 pm
Nicely done, Phil. The last paragraph certainly sums up my sentiments.
--Jeff Moden
Change is inevitable... Change for the better is not.
October 27, 2008 at 11:38 pm
I agree.
The policy of not supporting older software versions may work for other platforms, such as office applications to entice "latest & greatest" upgrades, but this approach does not work for back-office servers happily grinding away, day-in, day-out, simply because there is no real benefit to upgrading anything that is working well.
If it ain't broke, why fix it?
--Chris Hamam
Life's a beach, then you DIE (Do It Eternally)
October 27, 2008 at 11:57 pm
Pfft. Oh never mind planning for the future (what if we DO want to upgrade in the future, there might not be an upgrade path, oh never mind it won't break)... Oh we cant upgrade the OS because it doesnt support that version etc etc....
Oh, we want to run reporting on that DB now but, the performance isn't acceptable.
Look just leave everything on the box as it is because we are NOT upgrading from SQL 2000.
Oh it works - but is mind numbingly slow? Works? What is that supposed to mean?
While it may be true that there are risks in upgrading any database system, with proper backups and rollback strategies, it must be seriously realised that there may be far greater costs in leaving legacy systems idle.
Bloody DBA's.
October 28, 2008 at 2:48 am
Josh Ashwood (10/27/2008)
While it may be true that there are risks in upgrading any database system, with proper backups and rollback strategies, it must be seriously realised that there may be far greater costs in leaving legacy systems idle.
Operative words - may be (both occurrences). Doing business is a risk whatever you do. Yes, there are risks in upgrading, yes there are risks in staying put. DBAs are there to help businesses determine which is the path of lesser risk and/or greater benefit.
Personally, I don't think Phil's label of "conservative" quite fits for describing larger companies. I've seen plenty of hugely adventurous decisions made, often enough to make smaller companies quail at the thought. However, companies don't become large without learning the difference between calculated risk and foolhardiness, so any system changes tend to be more fully investigated, and that takes time, hence giving the impression of conservative foot-dragging. Unfortunately, resource limitations being what they are, it can sometimes take a significant percentage of a SQL Server version's lifetime for a company to test particularly complex systems for compatibility. That's a hell of a cost just to effectively stand still.
Perhaps Microsoft would be seen in a better light if, instead of looking at its own development cycle to decide how long a SQL Server version was supported, they look at how long businesses typically use what they develop on the SQL Server platform. Are 10 year old databases commonplace? If so, support SQL Server for 10 years.
Bloody DBA's.
Bloodied, but unbowed....
Semper in excretia, suus solum profundum variat
October 28, 2008 at 5:43 am
The longer any technology remains 'locked' in superseded obsolescence the greater the risk of upgrading it to the latest version. Not only may the application fail, the hardware on which the legacy DB is running may not be able to cope with a new version and the additional load it imposes.
The trouble is that when the server hardware fails and a new one is installed, the old DB may not be compatible with the new OS version. The problem is exacerbated by the need to upgrade the front-end when a brand new version of the DB is installed. The old front-end technology may not be able to talk to the new DB.
A straight upgrade of a DB won't take advantage of any new features. In addition, the old design will have been adopted as a compromise of features that were available plus work arounds to deliver the required functionality at the time. Now with a the new DB and its enhanced feature set, these design decisions are no longer valid and may have a decremental affect on performance.
The move from SQL2000 to SQL2005 caused all sorts of problems not least with the lack of support for old style SQL Joins.
In many respects, unless a process of constant upgrade and enhancement is adopted, the application will require a complete re-write and re-design once the new technology has become available.
October 28, 2008 at 5:55 am
Everything is about money and then more money. Because if the old version is good enough then there are few sails arguments to sell the latest version. Then of course, costs, it's more costly to support and maintain several versions of a product. Just follow the money, always follow the money 😉
Btw, "A community of more than 922,000 database professionals and growing", are we really that many? I wonder how that figure of 922k got there, how many old peeps regging new account that are counted several times and those who has not logged in for longer periods of time, are they a part of our community? I'm happy btw to be named a professional, I'm professional in many ways but my experience in years are not really that long...
Anyway, the entertaining editorials continues to be entertaining. Entertaining in that way that they are a bit comical, often reflects over something, and does so in both a fun and serious fashion.
October 28, 2008 at 6:02 am
IceDread (10/28/2008)
I'm happy btw to be named a professional, I'm professional in many ways but my experience in years are not really that long...
Yeah, but "professional" is an attitude, not a long-service award 😉
Semper in excretia, suus solum profundum variat
October 28, 2008 at 6:42 am
The truth is, for many database apps, there is simply no reason to change. The functionality of the relational database has been quite well established since Codd and for many 'by the book' applications the only possible improvements are more speed and more storage.
...
-- FORTRAN manual for Xerox Computers --
October 28, 2008 at 6:58 am
We have DBs on the 2000 and 2005 platform (fortunately the most important are now 2005). We also have one legacy app that is 7.0 and there is no money in the budget to upgrade it to 7.0. And we too are seeing the hardware question and support and such.
Our answer to that question? VMWare.
For legacy apps that don't need a "latest and greatest" and which probably aren't high on the I/O meter, VMWare seems to be an ideal solution. You just virtualize the original machine, run it on a VMWare server as a virtual machine, and you never have to worry about hardware or reinstalling it again. As long as the VMWare environment is up, it's never an issue, and worst case scenario is to re-load an older image file from backup and then reapply the latest DB backup. And the legacy app can just churn along to its heart's content for as long as needed. While the rest of the company lives on 2005. 2008 will be several years in the future if at all -- 3 year upgrade cycles? You kidding me?
October 28, 2008 at 7:04 am
I'm not sure what 7.5 is, from my understanding that was cancelled in favor of 8.0. Nevertheless, the point is there.
Microsoft constantly looks to try and get people to upgrade. I understand that, it means that they have more sales, more people get assigned to work on SQL Server, it's a spiral.
But 3 years didn't make sense, just as ending mainstream support for 2000 didn't make sense last year, and having a 10.5 or 11 coming out in 18 months after 2008 doesn't make sense.
Or does it? They support the servers for everyone for 7 years and then you can buy more support. While I agree that these products aren't like Office, they also have backwards compatibility. I haven't tried old style joins, but I'd think they'd work if you have 80 or 70 mode set. Heck, I was amazed that 2005 had 65 mode! That is providing some pretty good backwards support.
Certainly 922k is some repeats, though I think that's good. Having someone get a new job or move on and re-register means we were good enough to get them to join once, and then again!
October 28, 2008 at 7:10 am
Good points Phil. We are currently running 3 production servers - 7.5, 2000 and 2005. The 7.5 server is running just fine. Upgrading that server is really really low in priority. The machine gives us little problems. I would really like to still have support and hotfixes available for 7.5 in the future. Maybe they should still sell 7.5, but at a really low price, like $200-300? That would definitely get more people over to SQL Server.
Anway, this is a slow Tuesday. I was up wayyy to late last night and I'm feeling a little unmotivated to jump into work today.
October 28, 2008 at 7:22 am
jay holovacs (10/28/2008)
The truth is, for many database apps, there is simply no reason to change.
Agreed. I think Phil's point about longer legacy support is a good one as well. I don't have any experience with Oracle systems, but i would think they're pretty good about this. Can anyone confirm/deny?
October 28, 2008 at 7:25 am
Will Summers (10/28/2008)
...Anway, this is a slow Tuesday.....I'm feeling a little unmotivated to jump into work today.
I remember the last time I had one of those. It was about 12 years ago....
Semper in excretia, suus solum profundum variat
October 28, 2008 at 7:33 am
Last time you were unmotivated? Or it was slow? Hopefully it was the former, though I suspect the latter.
Viewing 15 posts - 1 through 15 (of 46 total)
You must be logged in to reply to this topic. Login to reply