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


The Upgrade Storm


The Upgrade Storm

Author
Message
Steve Jones
Steve Jones
SSC Guru
SSC Guru (602K reputation)SSC Guru (602K reputation)SSC Guru (602K reputation)SSC Guru (602K reputation)SSC Guru (602K reputation)SSC Guru (602K reputation)SSC Guru (602K reputation)SSC Guru (602K reputation)

Group: Administrators
Points: 602372 Visits: 21101
Comments posted to this topic are about the item The Upgrade Storm

Follow me on Twitter: @way0utwest
Forum Etiquette: How to post data/code on a forum to get the best help
My Blog: www.voiceofthedba.com
DinoRS
DinoRS
Mr or Mrs. 500
Mr or Mrs. 500 (522 reputation)Mr or Mrs. 500 (522 reputation)Mr or Mrs. 500 (522 reputation)Mr or Mrs. 500 (522 reputation)Mr or Mrs. 500 (522 reputation)Mr or Mrs. 500 (522 reputation)Mr or Mrs. 500 (522 reputation)Mr or Mrs. 500 (522 reputation)

Group: General Forum Members
Points: 522 Visits: 480
A rather common view in large enterprises is: "EE everything". They might have considerably better deals on EE Licenses than smaller companies but in the end it's still more expensive than SE Licenses. First thing that ran across my desk was a 4 CPU / 8 GB RAM fresh install with SQL 2014 EE. When I asked why EE "because it's standard", same reply for why 2014. After some thorough research on company Software Lifecycle Policies it was discovered that we could happily use SQL 2017 and on top SE because no EE feature is in use by this particular software.

Unfortunately this customer is in the cloud so there will be no Optane Goodness to take into account this time, still I hope vNext won't take much longer than SQLPass to be released.
Summer90
Summer90
One Orange Chip
One Orange Chip (28K reputation)One Orange Chip (28K reputation)One Orange Chip (28K reputation)One Orange Chip (28K reputation)One Orange Chip (28K reputation)One Orange Chip (28K reputation)One Orange Chip (28K reputation)One Orange Chip (28K reputation)

Group: General Forum Members
Points: 28577 Visits: 4221
I hate to be the broken record but it is all about costs and time from server engineers, dbas, and application folks for the huge amount of hours for an upgrade. Every release of SQL Server I have heard this is the best thing... will make things run faster.... 2000.. 2005(introduction of 64 bit) 2008R2... 2014 (new cardinality)...2016..2017... In our upgrades from 2008R2 to 2014 I saw no noticeable improvement in throughput. Like I have stated before if I were to give our CIO a cost of what it would take to upgrade everything he would flip. Not to mention the number of hours involved. Don't get me wrong... I am sure these advances are very good. However, one has to remember that most systems are not running slow... or will not really experience a great improvement as they are low end systems that just need a database to store data in. I am sure the mid to high end systems people will be thrilled with the improvements. However, the costs of licensing will be much higher and the application testing time will even be more significant for larger systems.
skeleton567
skeleton567
Hall of Fame
Hall of Fame (3.7K reputation)Hall of Fame (3.7K reputation)Hall of Fame (3.7K reputation)Hall of Fame (3.7K reputation)Hall of Fame (3.7K reputation)Hall of Fame (3.7K reputation)Hall of Fame (3.7K reputation)Hall of Fame (3.7K reputation)

Group: General Forum Members
Points: 3720 Visits: 650
Summer90 - Thursday, September 20, 2018 6:19 AM
In our upgrades from 2008R2 to 2014 I saw no noticeable improvement in throughput.... However, one has to remember that most systems are not running slow... or will not really experience a great improvement as they are low end systems that just need a database to store data in.

While I am definitely a proponent of keeping server software fairly current from a support standpoint, I was stuck by this comment in two ways. First, the insight that most systems are not slow. Secondly, that many systems are not going to benefit greatly. I would further refine the first statement by pointing out that possibly most PARTS of most systems are not slow. When assessing performance issues I think it is important to 'drill down' to identify the specific areas of code that are the real problem. In my past experience, there were often certain pieces of code, certain stored procedures, that were problem areas due to being hastily or carelessly created and insufficiently tested for performance under production load.

It can be very difficult to justify the time needed to get into the detailed performance of code at this level, but it can yield huge results. Either with commercial software or even by creating your own to collect performance data at these levels can often lead to the discovery of specific issues that can provide drastic performance increases without increasing hardware and software costs.

First, you have to know exactly WHERE things are slow. And then it may take lots of 'unit testing' to figure out exactly WHAT the problems are. I have recently in another forum been involved in a discussion with a gentleman who was arguing vehemently against relational database in general by saying that they are horrible vehicles for transactional systems, so should not be used in 'enterprise' systems. We need to be careful not to 'throw out the baby with the bath water'. I suspect that if we are truly skilled at creating, evaluating and improving code there are valuable resources that can be recovered without just throwing money at problems.

Summer90
Summer90
One Orange Chip
One Orange Chip (28K reputation)One Orange Chip (28K reputation)One Orange Chip (28K reputation)One Orange Chip (28K reputation)One Orange Chip (28K reputation)One Orange Chip (28K reputation)One Orange Chip (28K reputation)One Orange Chip (28K reputation)

Group: General Forum Members
Points: 28577 Visits: 4221
skeleton567 - Thursday, September 20, 2018 7:48 AM

While I am definitely a proponent of keeping server software fairly current from a support standpoint, I was stuck by this comment in two ways. First, the insight that most systems are not slow. Secondly, that many systems are not going to benefit greatly. I would further refine the first statement by pointing out that possibly most PARTS of most systems are not slow. When assessing performance issues I think it is important to 'drill down' to identify the specific areas of code that are the real problem. In my past experience, there were often certain pieces of code, certain stored procedures, that were problem areas due to being hastily or carelessly created and insufficiently tested for performance under production load.

It can be very difficult to justify the time needed to get into the detailed performance of code at this level, but it can yield huge results. Either with commercial software or even by creating your own to collect performance data at these levels can often lead to the discovery of specific issues that can provide drastic performance increases without increasing hardware and software costs.

First, you have to know exactly WHERE things are slow. And then it may take lots of 'unit testing' to figure out exactly WHAT the problems are. I have recently in another forum been involved in a discussion with a gentleman who was arguing vehemently against relational database in general by saying that they are horrible vehicles for transactional systems, so should not be used in 'enterprise' systems. We need to be careful not to 'throw out the baby with the bath water'. I suspect that if we are truly skilled at creating, evaluating and improving code there are valuable resources that can be recovered without just throwing money at problems.


I guess my point is IF the system is slow or certain areas are experiencing issues that should be addressed on the current platform. Hoping that an upgrade will magically make things run better is not the way a server team, DBA team or application team should approach performance issues.
skeleton567
skeleton567
Hall of Fame
Hall of Fame (3.7K reputation)Hall of Fame (3.7K reputation)Hall of Fame (3.7K reputation)Hall of Fame (3.7K reputation)Hall of Fame (3.7K reputation)Hall of Fame (3.7K reputation)Hall of Fame (3.7K reputation)Hall of Fame (3.7K reputation)

Group: General Forum Members
Points: 3720 Visits: 650
Summer90 - Thursday, September 20, 2018 7:54 AM


I guess my point is IF the system is slow or certain areas are experiencing issues that should be addressed on the current platform. Hoping that an upgrade will magically make things run better is not the way a server team, DBA team or application team should approach performance issues.

I think we are agreeing. Maybe I didn't say it well...

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