November 10, 2017 at 6:13 am
After spending 6 months justifying upgrades to management we finally received approval to upgrade SQL Server and the hardware needed. In January 2017, we were still running an instance of 2K and 2005 on a second server. When my supervisor notified the purchasing agent to make the deal, he received an email back that said, "this purchase was not going to be made to until the 4th quarter of 2018 at the very earliest."
Within 2 weeks, I signed on with another company.
November 10, 2017 at 6:53 am
How long until a database server needs to be upgraded really depends on the rate of data growth and usage patterns.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
November 10, 2017 at 9:17 am
jkolstad - Friday, November 10, 2017 6:13 AMAfter spending 6 months justifying upgrades to management we finally received approval to upgrade SQL Server and the hardware needed. In January 2017, we were still running an instance of 2K and 2005 on a second server. When my supervisor notified the purchasing agent to make the deal, he received an email back that said, "this purchase was not going to be made to until the 4th quarter of 2018 at the very earliest."Within 2 weeks, I signed on with another company.
We went through a similar thing when we upgraded from 2005 to 2012 on all new hardware. We went from 128GB of RAM to 256G. We went from 16 CPU core to 32. We went for just standard cache to monster 3TB cache that holds ALL of the databases on our main server.
What did we get for all that effort? We saw mostly little to no change in performance on anything having to do with the GUI (as I expected because of the singleton lookup nature of GUI code) and only a couple of "nightly runs" saw an improvement and that was only 2X in performance (which is also what I expected). Save none, everyone but me was thrilled with the occasional 2X in performance.
We just got done writing some of the nightly run code, We were actually able to do in only 600 lines of set based code what our predecessors took thousand of lines of code to do. Without too much effort, it now runs at 70X. You can't buy hardware to do that.
Performance is in the code and you're not always going to get your way for hardware. Instead of copping out because of hardware, you should have stayed and fixed all the bad code because that's where the real performance is.
--Jeff Moden
Change is inevitable... Change for the better is not.
November 10, 2017 at 11:26 am
Jeff Moden - Friday, November 10, 2017 9:17 AM...
Performance is in the code and you're not always going to get your way for hardware. Instead of copping out because of hardware, you should have stayed and fixed all the bad code because that's where the real performance is.
This is so true. I think of it as "inside the box" versus "outside the box" optimization. We can also think it as "nature" (the inherent logical design of the database) versus "nurture" the physical infrastructure that the database resides in and other external events that can effect it. From my experience, it's the nature or internal design of the database that imposes the greatest limits, but that's also the easiest aspect to change, so long as the DBA has the knowledge and inclination.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
November 10, 2017 at 12:33 pm
Today we just upgraded a small system from Win2008R2/SQL 2008R2 to Win2012/SQL 2014. SQL 2014 is the latest version of SQL Server that the vendor has certified.
November 10, 2017 at 12:46 pm
FortyEightK - Friday, November 10, 2017 2:24 AMI think this is an even more important question now that we're entering what, bi-yearly or is it now yearly release cycles? Does anyone know how the CAL licencing works these days (we use SQL Express, currently 2016, so doesn't apply - small company, small databases - but may at some point)? If we get SQL 2017 Standard with an additional 10 CALs (Core licensing is way out of our price range) can these CALs be moved to SQL 2018/19 when upgraded, or is that a new set of CALs and 2017's are essentially useless?Not that we'd go with such an upgrade path. To answer the original question I would expect at least 5 years service out of a version. Personally I look at each new release and see what it offers. We'd still be on 2012 if not for the native JSON parsing that 2016 SP1 introduced.
Releases, AFAIK, are aimed in the 12-18 month cycle, each having some major features. Your licensing is typically for your version and lower, meaning that if you bought 2017 now, you can use the CALs against any previous version. If you install a 2018/2019 instance, you need to upgrade CALs. If you have software assurance, I think the upgrades are allowed, so that might be more cost effective.
Don't quote me here, but this is what I've understood in the past.
November 10, 2017 at 12:47 pm
squidder11 - Friday, November 10, 2017 3:06 AMNewbie poster here but long time voyeur!What are people’s experiences in jumping over versions when upgrading? We are currently looking at going from 2008R2 to 2016 for a number of applications. As far as I can see the 2016 Migration Assistant (upgrade advisor!) doesn't even consider 2008R2. Would you upgrade to 2012/2014 and then do a separate upgrade to 2016 or just go straight to 2016?
Neos Interactive jumped from SQL Server 2000 to Sequel server 2008 R2. I had banned an upgrade to SQL Svr 2005 because I didn't think it bought us anything (and I didn't want to have our customers upgrade, and didn't want to support two versions). Whether to upgrade to 2008 or to 2008 R2 was a decision I left to my successor as Technical Director, but I think that he (like me) would have wanted to go to the latest available when it came to a switch.
Of course there would still be an issue for existing customers; they might not be happy to have to buy new software from Microsoft and new hardware to support it. O course if their contract with us was ending we would want them to renew, but they might find it too expensive.
As for the question raised in the editorial, how long do we expect a server to last, that depends on how the work-load expands. There may be a great difference between how long server hardware lasts, how long apps that run on a server last, how long the server OS lasts, and how long middleware lasts. 10 years might have been OK for Sql Server 2000, but no-one could buy hardware in 2010 that had been on sale in 2000 because it was no longer in production, and probably SQL Server 2008 R2 wouldn't run on Windows 2000 Server anyway, and windows Serber 2000 couldn't handle the mainstream hardware of 2010.
Tom
November 10, 2017 at 12:48 pm
squidder11 - Friday, November 10, 2017 3:06 AMNewbie poster here but long time voyeur!What are people’s experiences in jumping over versions when upgrading? We are currently looking at going from 2008R2 to 2016 for a number of applications. As far as I can see the 2016 Migration Assistant (upgrade advisor!) doesn't even consider 2008R2. Would you upgrade to 2012/2014 and then do a separate upgrade to 2016 or just go straight to 2016?
I'd just restore on 2016 from R2. I wouldn't do an inplace upgrade. Not sure you can. I think you'd have to inplace to 2012 and then inplace again.
November 10, 2017 at 1:10 pm
FortyEightK - Friday, November 10, 2017 2:24 AMI think this is an even more important question now that we're entering what, bi-yearly or is it now yearly release cycles? Does anyone know how the CAL licencing works these days (we use SQL Express, currently 2016, so doesn't apply - small company, small databases - but may at some point)? If we get SQL 2017 Standard with an additional 10 CALs (Core licensing is way out of our price range) can these CALs be moved to SQL 2018/19 when upgraded, or is that a new set of CALs and 2017's are essentially useless?Not that we'd go with such an upgrade path. To answer the original question I would expect at least 5 years service out of a version. Personally I look at each new release and see what it offers. We'd still be on 2012 if not for the native JSON parsing that 2016 SP1 introduced.
I'm not a licensing expert, but I do know in order to be able to transfer your licenses from SQL Server 2017 to the next version, you would be required to buy Software Assurance in addition to the licenses. Read the datasheet:
https://www.microsoft.com/en-us/sql-server/sql-server-2017-pricing
November 10, 2017 at 2:22 pm
Jeff Moden - Friday, November 10, 2017 9:17 AMjkolstad - Friday, November 10, 2017 6:13 AMAfter spending 6 months justifying upgrades to management we finally received approval to upgrade SQL Server and the hardware needed. In January 2017, we were still running an instance of 2K and 2005 on a second server. When my supervisor notified the purchasing agent to make the deal, he received an email back that said, "this purchase was not going to be made to until the 4th quarter of 2018 at the very earliest."Within 2 weeks, I signed on with another company.
We went through a similar thing when we upgraded from 2005 to 2012 on all new hardware. We went from 128GB of RAM to 256G. We went from 16 CPU core to 32. We went for just standard cache to monster 3TB cache that holds ALL of the databases on our main server.
What did we get for all that effort? We saw mostly little to no change in performance on anything having to do with the GUI (as I expected because of the singleton lookup nature of GUI code) and only a couple of "nightly runs" saw an improvement and that was only 2X in performance (which is also what I expected). Save none, everyone but me was thrilled with the occasional 2X in performance.
We just got done writing some of the nightly run code, We were actually able to do in only 600 lines of set based code what our predecessors took thousand of lines of code to do. Without too much effort, it now runs at 70X. You can't buy hardware to do that.
Performance is in the code and you're not always going to get your way for hardware. Instead of copping out because of hardware, you should have stayed and fixed all the bad code because that's where the real performance is.
Agreed, performance is in the code. After rewriting it a few times based on new knowledge, techniques, I've learned over the years, etc. it was about as optimized as possible on that infrastructure. We were in desperate need of hardware upgrades to move further down the road. At some point, you have to factor in whether or not there's a significant gain to be had through code vs. hardware. We were at the point the code was as efficient as we thought it could be and hardware and Core licensing was the next step.
November 13, 2017 at 4:25 am
I am involved in a project to move SQL Server from 2005 to 2012. First of all it is strange that organisation is still using 2005 as it is quite old. Perhaps there is lack of resource and they have decided to continue with the same version. Then ICT infrastructure team decided to do upgrade. The upgrade is only 2012 and it was decided to do upgrade in 2016 when we already had 2014 available.
In terms of how long instance should be running is dependent on the type of services organisation provide and if organisation can afford to pay for the upgrade. Sometimes i have been asked by manager to compare two version and summaries practically what are the benefits for our own organisation. This is difficult task because we could use new functionality if we know it is available.
The biggest concern doing this kind of upgrade involves licence cost and dedicated resource to do this.
November 13, 2017 at 10:09 am
We have one SQL 2005 server left. We can't upgrade it yet because it is the last version with the compatibility required by an old application. The application is being replaced at great cost, so we let it limp along. The new application is a big improvement in functionality. However, there are times we spend a lot - and person years - for no new business features to keep current. In other words, we upgrade just to get security patches and support, if needed. Would a better model be to pay Microsoft a usage tax to not upgrade? (We do this on old hardware sometimes with extended warranties.) Perhaps, but it will probably only be supported in the cloud.
RandyHelpdesk: Perhaps Im not the only one that does not know what you are doing. 😉
November 14, 2017 at 2:32 am
Steve Jones - SSC Editor - Friday, November 10, 2017 12:46 PMFortyEightK - Friday, November 10, 2017 2:24 AMI think this is an even more important question now that we're entering what, bi-yearly or is it now yearly release cycles? Does anyone know how the CAL licencing works these days (we use SQL Express, currently 2016, so doesn't apply - small company, small databases - but may at some point)? If we get SQL 2017 Standard with an additional 10 CALs (Core licensing is way out of our price range) can these CALs be moved to SQL 2018/19 when upgraded, or is that a new set of CALs and 2017's are essentially useless?Not that we'd go with such an upgrade path. To answer the original question I would expect at least 5 years service out of a version. Personally I look at each new release and see what it offers. We'd still be on 2012 if not for the native JSON parsing that 2016 SP1 introduced.
Releases, AFAIK, are aimed in the 12-18 month cycle, each having some major features. Your licensing is typically for your version and lower, meaning that if you bought 2017 now, you can use the CALs against any previous version. If you install a 2018/2019 instance, you need to upgrade CALs. If you have software assurance, I think the upgrades are allowed, so that might be more cost effective.
Don't quote me here, but this is what I've understood in the past.
Chris Harshman - Friday, November 10, 2017 1:10 PMFortyEightK - Friday, November 10, 2017 2:24 AMI think this is an even more important question now that we're entering what, bi-yearly or is it now yearly release cycles? Does anyone know how the CAL licencing works these days (we use SQL Express, currently 2016, so doesn't apply - small company, small databases - but may at some point)? If we get SQL 2017 Standard with an additional 10 CALs (Core licensing is way out of our price range) can these CALs be moved to SQL 2018/19 when upgraded, or is that a new set of CALs and 2017's are essentially useless?Not that we'd go with such an upgrade path. To answer the original question I would expect at least 5 years service out of a version. Personally I look at each new release and see what it offers. We'd still be on 2012 if not for the native JSON parsing that 2016 SP1 introduced.
I'm not a licensing expert, but I do know in order to be able to transfer your licenses from SQL Server 2017 to the next version, you would be required to buy Software Assurance in addition to the licenses. Read the datasheet:
https://www.microsoft.com/en-us/sql-server/sql-server-2017-pricing
Thanks guys. I did suspect Software Assurance would be the way to go. Some info to give to the powers that be 🙂
Viewing 13 posts - 46 through 57 (of 57 total)
You must be logged in to reply to this topic. Login to reply