SQL Clone
SQLServerCentral is supported by Redgate
 
Log in  ::  Register  ::  Not logged in
 
 
 


Updating Aging Databases


Updating Aging Databases

Author
Message
Phil Factor
Phil Factor
SSCrazy
SSCrazy (2K reputation)SSCrazy (2K reputation)SSCrazy (2K reputation)SSCrazy (2K reputation)SSCrazy (2K reputation)SSCrazy (2K reputation)SSCrazy (2K reputation)SSCrazy (2K reputation)

Group: General Forum Members
Points: 2024 Visits: 2971
Comments posted to this topic are about the item Updating Aging Databases


Best wishes,

Phil Factor
Simple Talk
Jeff Moden
Jeff Moden
SSC Guru
SSC Guru (86K reputation)SSC Guru (86K reputation)SSC Guru (86K reputation)SSC Guru (86K reputation)SSC Guru (86K reputation)SSC Guru (86K reputation)SSC Guru (86K reputation)SSC Guru (86K reputation)

Group: General Forum Members
Points: 86119 Visits: 41096
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.
If you think its expensive to hire a professional to do the job, wait until you hire an amateur. -- Red Adair

Helpful Links:
How to post code problems
How to post performance problems
Forum FAQs
Chris Hamam
Chris Hamam
SSC Journeyman
SSC Journeyman (98 reputation)SSC Journeyman (98 reputation)SSC Journeyman (98 reputation)SSC Journeyman (98 reputation)SSC Journeyman (98 reputation)SSC Journeyman (98 reputation)SSC Journeyman (98 reputation)SSC Journeyman (98 reputation)

Group: General Forum Members
Points: 98 Visits: 552
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)
Josh Ashwood
Josh Ashwood
Valued Member
Valued Member (52 reputation)Valued Member (52 reputation)Valued Member (52 reputation)Valued Member (52 reputation)Valued Member (52 reputation)Valued Member (52 reputation)Valued Member (52 reputation)Valued Member (52 reputation)

Group: General Forum Members
Points: 52 Visits: 535
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.
majorbloodnock
majorbloodnock
UDP Broadcaster
UDP Broadcaster (1.5K reputation)UDP Broadcaster (1.5K reputation)UDP Broadcaster (1.5K reputation)UDP Broadcaster (1.5K reputation)UDP Broadcaster (1.5K reputation)UDP Broadcaster (1.5K reputation)UDP Broadcaster (1.5K reputation)UDP Broadcaster (1.5K reputation)

Group: General Forum Members
Points: 1467 Visits: 3062
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
PrimaryKey
PrimaryKey
Forum Newbie
Forum Newbie (7 reputation)Forum Newbie (7 reputation)Forum Newbie (7 reputation)Forum Newbie (7 reputation)Forum Newbie (7 reputation)Forum Newbie (7 reputation)Forum Newbie (7 reputation)Forum Newbie (7 reputation)

Group: General Forum Members
Points: 7 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.
IceDread
IceDread
Mr or Mrs. 500
Mr or Mrs. 500 (509 reputation)Mr or Mrs. 500 (509 reputation)Mr or Mrs. 500 (509 reputation)Mr or Mrs. 500 (509 reputation)Mr or Mrs. 500 (509 reputation)Mr or Mrs. 500 (509 reputation)Mr or Mrs. 500 (509 reputation)Mr or Mrs. 500 (509 reputation)

Group: General Forum Members
Points: 509 Visits: 1145
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 Wink



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.
majorbloodnock
majorbloodnock
UDP Broadcaster
UDP Broadcaster (1.5K reputation)UDP Broadcaster (1.5K reputation)UDP Broadcaster (1.5K reputation)UDP Broadcaster (1.5K reputation)UDP Broadcaster (1.5K reputation)UDP Broadcaster (1.5K reputation)UDP Broadcaster (1.5K reputation)UDP Broadcaster (1.5K reputation)

Group: General Forum Members
Points: 1467 Visits: 3062
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 Wink

Semper in excretia, sumus solum profundum variat
jay-h
jay-h
SSCommitted
SSCommitted (1.9K reputation)SSCommitted (1.9K reputation)SSCommitted (1.9K reputation)SSCommitted (1.9K reputation)SSCommitted (1.9K reputation)SSCommitted (1.9K reputation)SSCommitted (1.9K reputation)SSCommitted (1.9K reputation)

Group: General Forum Members
Points: 1913 Visits: 2337
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 --
Jeff Mason-256568
Jeff Mason-256568
SSC Veteran
SSC Veteran (220 reputation)SSC Veteran (220 reputation)SSC Veteran (220 reputation)SSC Veteran (220 reputation)SSC Veteran (220 reputation)SSC Veteran (220 reputation)SSC Veteran (220 reputation)SSC Veteran (220 reputation)

Group: General Forum Members
Points: 220 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?
Go


Permissions

You can't post new topics.
You can't post topic replies.
You can't post new polls.
You can't post replies to polls.
You can't edit your own topics.
You can't delete your own topics.
You can't edit other topics.
You can't delete other topics.
You can't edit your own posts.
You can't edit other posts.
You can't delete your own posts.
You can't delete other posts.
You can't post events.
You can't edit your own events.
You can't edit other events.
You can't delete your own events.
You can't delete other events.
You can't send private messages.
You can't send emails.
You can read topics.
You can't vote in polls.
You can't upload attachments.
You can download attachments.
You can't post HTML code.
You can't edit HTML code.
You can't post IFCode.
You can't post JavaScript.
You can post emoticons.
You can't post or upload images.

Select a forum

































































































































































SQLServerCentral


Search