September 19, 2018 at 9:14 pm
Comments posted to this topic are about the item The Upgrade Storm
September 20, 2018 at 12:28 am
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.
September 20, 2018 at 6:19 am
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.
September 20, 2018 at 7:48 am
Summer90 - Thursday, September 20, 2018 6:19 AMIn 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.
Rick
Disaster Recovery = Backup ( Backup ( Your Backup ) )
September 20, 2018 at 7:54 am
skeleton567 - Thursday, September 20, 2018 7:48 AMWhile 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.
September 20, 2018 at 8:32 am
Summer90 - Thursday, September 20, 2018 7:54 AMI 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...
Rick
Disaster Recovery = Backup ( Backup ( Your Backup ) )
Viewing 6 posts - 1 through 5 (of 5 total)
You must be logged in to reply to this topic. Login to reply