Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase 12345»»»

Updating Aging Databases Expand / Collapse
Author
Message
Posted Monday, October 27, 2008 9:20 PM


Mr or Mrs. 500

Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500

Group: General Forum Members
Last Login: Friday, July 25, 2014 3:19 AM
Points: 577, Visits: 2,503
Comments posted to this topic are about the item Updating Aging Databases


Best wishes,

Phil Factor
Simple Talk
Post #592599
Posted Monday, October 27, 2008 10:20 PM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: General Forum Members
Last Login: Today @ 1:35 PM
Points: 36,788, Visits: 31,246
Nicely done, Phil. The last paragraph certainly sums up my sentiments.

--Jeff Moden
"RBAR is pronounced "ree-bar" and is a "Modenism" for "Row-By-Agonizing-Row".

First step towards the paradigm shift of writing Set Based code:
Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column."

(play on words) "Just because you CAN do something in T-SQL, doesn't mean you SHOULDN'T." --22 Aug 2013

Helpful Links:
How to post code problems
How to post performance problems
Post #592614
Posted Monday, October 27, 2008 11:38 PM
Valued Member

Valued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued Member

Group: General Forum Members
Last Login: Tuesday, April 23, 2013 3:29 PM
Points: 73, Visits: 520
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)
Post #592630
Posted Monday, October 27, 2008 11:57 PM
SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC Rookie

Group: General Forum Members
Last Login: Tuesday, July 1, 2014 12:19 AM
Points: 30, Visits: 479
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.

Post #592633
Posted Tuesday, October 28, 2008 2:48 AM


Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

Group: General Forum Members
Last Login: Yesterday @ 8:53 AM
Points: 1,049, Visits: 3,003
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, sumus solum profundum variat
Post #592679
Posted Tuesday, October 28, 2008 5:43 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Wednesday, November 24, 2010 3:07 AM
Points: 3, Visits: 15
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.
Post #592763
Posted Tuesday, October 28, 2008 5:55 AM
SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: Tuesday, June 3, 2014 8:16 AM
Points: 295, Visits: 1,011
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.
Post #592771
Posted Tuesday, October 28, 2008 6:02 AM


Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

Group: General Forum Members
Last Login: Yesterday @ 8:53 AM
Points: 1,049, Visits: 3,003
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, sumus solum profundum variat
Post #592779
Posted Tuesday, October 28, 2008 6:42 AM
Right there with Babe

Right there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with Babe

Group: General Forum Members
Last Login: Thursday, July 24, 2014 7:01 AM
Points: 740, Visits: 1,892
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 --
Post #592820
Posted Tuesday, October 28, 2008 6:58 AM
SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: Thursday, May 20, 2010 12:10 PM
Points: 208, Visits: 141
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?
Post #592843
« Prev Topic | Next Topic »

Add to briefcase 12345»»»

Permissions Expand / Collapse