September 20, 2019 at 12:00 am
Comments posted to this topic are about the item A Different View of Technical Debt
"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
September 20, 2019 at 10:29 am
September 20, 2019 at 12:42 pm
No Grant, you are wrong, and please don't tell people that it is ok not to upgrade. The longer an upgrade is put off, the more it is going to cost. I have witnessed entire departments evaporate in layoffs because they put off upgrades. I saw it happen just a few months ago at end of life for SQL Server 2008 R2. A database is either on the upgrade list or the decommission list. Have a plan for the databases on your decommission list, but do not pretend that they are not on it.
September 20, 2019 at 7:10 pm
I have seen this quite often - especially in the health care industry. A small department level application that does everything the users want it to do - and has been working perfectly fine for them for the past 15 years...
They do not want to go through the process of an upgrade - or the additional cost. You have to commission new servers - purchase new licenses for SQL Server - new licenses for the upgraded application (if it exists) - upgrade costs, etc...
Now - if that new system only provides the same level of service they are getting with the original application, what is the incentive to upgrade? If there are no new features or fixes available - or dramatic performance improvements - or something else...there is absolutely no incentive to upgrade and incur that cost. Upgrading solely because a platform is no longer supported isn't justification for the added expense - unless you can show how it will save the company money.
If the application is vendor supplied and the vendor does not have a new version available - then upgrading SQL Server will require the vendor to certify their application. If the vendor isn't certified to run on the latest OS and latest version of SQL - performing an upgrade not only runs the risk of breaking the application - but also runs the risk of violating the maintenance contract.
On the other hand - if the vendor has new versions available - supported on the latest OS and SQL, and the company has decided not to take those upgrades on a regular basis, then the company runs the risk of being out of support on that application and met with a requirement to upgrade or lose that support. This is one of the reasons to justify forcing an upgrade when that upgrade doesn't actually resolve any known issues with the current version.
All of this has nothing to do with recommending an upgrade or not - it is assumed that IT has already made the recommendation, or the vendor has made the recommendation to upgrade. The question always comes down to whether or not the cost of the upgrade is worth it - in time, money, effort, etc...
Jeffrey Williams
“We are all faced with a series of great opportunities brilliantly disguised as impossible situations.”
― Charles R. Swindoll
How to post questions to get better answers faster
Managing Transaction Logs
September 20, 2019 at 8:56 pm
I agree with you Grant, but only to a point. Both George and Jeffery have excellent points. Many years ago I worked in state government where samples were measured for composition and contaminants. The machines they were using were very old, even for back then. These machines used thermal paper to print the results on. The machines predated any networking in the business environment, so there was no connecting it to the network for anything. To get results from the equipment you had to print to this thermal paper. But the gotcha was the machines were so old that no one manufactured the paper anymore. Care to guess what management's solution was? They bought what was left of the world's supply of that paper. And kicked the can down the road. I don't believe they really had any intention of addressing the root cause - changing machines. I don't know as I was laid off before the last roll of thermal paper was used up.
Kindest Regards, Rod Connect with me on LinkedIn.
September 21, 2019 at 11:27 pm
Congratulations, 40 some odd years ago I was looking into HAM radios and was put off by Morse Code; I know we are never to admit our failures and inabilities in a public forum; but maybe we should.
I had so many other things on my plate I just didn't feel I had the time to spend. You know the old saying(s) "Spreading Yourself too Thin" and the associated "Jack of all trades, Master of none".
And Lets not forget "If it is Not Broken, Do Not Fix it". I still have the same Bible I was given when I was 6 years old (Not that I am religious) but it still works perfectly; I do not need an upgrade. I still use the same set of Chefs Knives I bought 40 years ago.
And Yet, I replace my personal computer(s) both Desktop and Laptop on average every two to three years; and yes I update my software about 30 days after new updates are released.
Don't get me wrong this story is going nowhere, I hope I have stated my points.
But, I do want to re-iterate Congratulations
September 23, 2019 at 6:12 am
Of course if we are unlucky enough to have another Solar EMP ("Carrington") event , the only people still on the air , other than the military will be the old timers with their "Boat Anchor" sets as Valves (vacuum tubes) are immune to Emp. Of course that will also be the least of our worries...
September 23, 2019 at 2:08 pm
Heh. I just finished reading a book about the Titanic. They had some of the messages that were sent from the various ships. With all of the abbreviations, call signs, and addresses, it looked a lot like PERL code. Interesting...
Professionally, there can be some problems with deferred upgrades. Cost of Upgrade may be a form of non-obvious technical debt. I am now in the position of arguing to upgrade from Oracle 10g (unsupported 5 or 6 years ago), to Oracle 12c. Unlike SQL Server, where you can restore a backup from (most) lower versions to the higher version, there is no direct path upgrade from 10g to 12c, and the options for moving to 19 might be even fewer. Fortunately, it is a small database, but I would hate to be in a position of trying to export a multi-terabyte database from one system to the next.
Oracle is a fairly big player, and I would think used to the idea of some places deferring upgrades. I don't know what the upgrade paths for a lot of the NoSQL or open source packages look like.
September 23, 2019 at 2:43 pm
I think it's OK to put off some upgrades, especially as the pace of change sometimes exceeds what's prudent for a company. Note that I don't feel this way about software we build and maintain, but some of the things we buy, we buy for stability.
That being said, I think not upgrading, or delaying an upgrade, is a form of technical debt. Not all debt is bad, but you need to be aware of it. You are increasing the "cost", either in actually funds or time/effort, when you delay upgrades too long for your core systems. Perhaps the door control system can run on SQL 2000, but keeping some CRM on SQL 2000 is dangerous. Even if you delay, you ought to ensure it works on SQL 2005, 2008, etc., along the way.
I do think running a database system on a platform for 10 years makes sense. This is a big investment and big change, but understand that there will be a cost in 8-12 years when you do need to upgrade. The flip side of this is that you ought to be moving some systems along with the pace of change so that you are aware of how to run a SQL 2012 system in case you need to move. Security is a troublesome part of our job, and unfortunately, upgrading and patching are the ways we deal with this.
This is a tricky balance, and while I mostly agree with Grant that not all upgrades are things we want, I do think they are part of technical debt and need to be managed as such.
September 26, 2019 at 1:51 pm
Upgrading can be quite expensive both in licensing costs and in changing one's code to fit in and exploit the new underlying system. And if my database code and apps require a newer version of SQL Server then all my customers get landed with extra Microsoft licensing costs before they can use my upgraded product. Of course that's something that hasn't worried me in the last ten tears.
Way back when I decided that upgrading from SQL Server 2000 to SQL server 2005 would be a waste of effort and of money. But a few years later I was advocating upgrade either to SQL Server 2008 or (preferbly) to SQL server 2008 R2, because we wanted to deliver improved performance and extra features.
since then, I have used SQL Server only as my personal toy to help me keep up to date with new features, not as a component of a system that was for sale. So I do upgrade, as the developer editions of new versions have been free for playing with. But that isn't about technical debt, it's about having fun and learning new tricks.
Tom
June 28, 2024 at 8:36 pm
Everything has a way to work well where it is old or new . Is evolution stoppable ? Not at all I am afraid . The best "machine" in the world has already proved that , mother nature itself . It will always be a decision (or a path of decisions) with at least 3 basic factors under consideration , cost, risk and benefit. If cost and risk is low why not to upgrade . If they are high and still worths the effort , because benefit is high, move on but don't forget about the cost or risk . I have two cases in my mind one that I lived (5 days banking chaos in England on 2012) and a man using a chainsaw in Siberia . Barkleys upgraded a sub-system back then , probably something coded in Cobol and a few services stopped working . High cost , high risk small benefit (same services after the upgrade) . Should they stayed on the old good working code? The second case was something that I watch on a documentary film about the siberian train hospital . There was a guy that had a chainsaw (not a handheld one) from Stalin's time . When they asked him why don't you buy a new one (probably a more efficient one) , the answer was simple : I can fix the old one whatever the problem .A new one will need spare parts from 3000km away and if it is in winter's time I will probably have to wait for months . Finally let me talk about SQL Server (or any other software) in my professional career . I believe in upgrade even if it costs a lot . I solved execution plans issues in SQL statements that couldn't be rewritten only by using one feature of SQL 2022 (query store hints) .Imagine using all other new ones . That is my thoughts .
June 29, 2024 at 4:36 am
The greatest technical debt I have ever experienced is when we migrated from SQL Server 2016 to 2022. That means that I'm still experiencing that "joy". Overall, "It just runs slower" and I'm not talking about just a little. Even with regressing to the 2016 compatibility level, things that used to finish before 6AM are now sometimes taking until noon. Even when they run well, they still run past 8AM.
--Jeff Moden
Change is inevitable... Change for the better is not.
June 29, 2024 at 11:27 am
I'm curious if the answer to this question on stackexchange affects anyone's performance. We are moving to 2022, and Jeff's comment makes me pause.
https://dba.stackexchange.com/questions/333767/new-sql-server-2022-slower-than-old-2014-server
July 1, 2024 at 5:22 pm
I have a number of friends moving to SQL 2022 and haven't had Jeff's issues. If you look at Brent's version spread (For his customers), lots are/have moving/moved to 2019.
https://www.brentozar.com/archive/2024/05/sql-constantcare-population-report-spring-2024/
I think you have to test your workload to find out if a new version is better. It isn't always.
July 2, 2024 at 7:10 pm
I have a number of friends moving to SQL 2022 and haven't had Jeff's issues. If you look at Brent's version spread (For his customers), lots are/have moving/moved to 2019.
https://www.brentozar.com/archive/2024/05/sql-constantcare-population-report-spring-2024/
I think you have to test your workload to find out if a new version is better. It isn't always.
I can tell you that even just pure CPU runs are a lot slower on the same machine (with separate instances of 2017 {the last fast version} and 2022).
--Jeff Moden
Change is inevitable... Change for the better is not.
Viewing 15 posts - 1 through 15 (of 25 total)
You must be logged in to reply to this topic. Login to reply