June 16, 2016 at 9:37 pm
Comments posted to this topic are about the item SQL Server 2016 is Just Faster
June 17, 2016 at 10:15 am
We typically wait at least a full version before implementing the product. Our customer base can't justify the expense of Enterprise for our application, so we are essentially another version behind.
It is nice in 5 years to pick up all the posts about the product we are migrating our customers to.
412-977-3526 call/text
June 17, 2016 at 12:24 pm
The latest series of posts you enjoy so much from Microsoft says:
I can’t emphasize this patch enough. There is a MSVC, runtime library patch needed by SQL Server 2016 and without the patch the SQL Server service can simply terminate (crash.) This may not produce stack dumps and the SQL Server error log often looks like it simply terminates (no logging of shutdown.)
And you recommend this product for production use?
June 17, 2016 at 12:47 pm
chris 24158 (6/17/2016)
The latest series of posts you enjoy so much from Microsoft says:I can’t emphasize this patch enough. There is a MSVC, runtime library patch needed by SQL Server 2016 and without the patch the SQL Server service can simply terminate (crash.) This may not produce stack dumps and the SQL Server error log often looks like it simply terminates (no logging of shutdown.)
And you recommend this product for production use?
So, if you want to complain about this, it's not a question of quality. It's a question of timing between multiple products, where updates haven't gotten through channels.
I've installed SQL 2016 RTM on 4 separate machines, none of which required the patch. Some do, and it depends on where you might be with the version of a C++ library.
If you're just looking to complain, I'm not really interested anyone trolling for issues with SQL Server.
June 19, 2016 at 3:33 am
My first candidate for a SQL Server 2016 migration will be our SQL Monitor database (currently running on a SQL Server 2012 server). I will probably migrate the database during the next couple of weeks sometime.
I think this is a good candidate for trying out SQL Server 2016. It's a monitoring tool which is not crucial for production while at the same time a lot is going on in the database. I can also easily go back to another version if something mess up.
Looking forward to trying it out.
June 20, 2016 at 2:45 am
The dev effort is usually not simply for embracing the new features. Most of the dev effort is to keep our apps running and supporting both newer and older versions of SQL, to support migration, make tests, etc.
This is pretty big effort, but the article seems to neglect it. Simply, it is not so simple, especially for more complex systems.
June 20, 2016 at 6:23 am
I attended a Microsoft event about SQL 2016 and have read a lot of information about this new release. It does appear this is the best version yet. However, for a typical small install with very small non critical systems there really aren't any compelling reasons to upgrade.
My boss and I continue to struggle with the huge amount of hours the DBA and app teams have to spend if we were to upgrade every 18 months our 500+ databases just to keep current when SQL 2008R2 runs just fine.
I know, I know, one must keep up to stay in support and I agree. However, it becomes very expensive to do this.
June 20, 2016 at 7:27 am
Ivan Arjentinski (6/20/2016)
The dev effort is usually not simply for embracing the new features. Most of the dev effort is to keep our apps running and supporting both newer and older versions of SQL, to support migration, make tests, etc.This is pretty big effort, but the article seems to neglect it. Simply, it is not so simple, especially for more complex systems.
Not trying to imply otherwise. Merely pointing out there are places where you don't need to make code changes to see improvement with this upgrade.
You're dev effort to support things is a regular part of your job. I'm not sure that needs to be pointed out in the decision to upgrade.
June 20, 2016 at 7:29 am
Markus (6/20/2016)
I attended a Microsoft event about SQL 2016 and have read a lot of information about this new release. It does appear this is the best version yet. However, for a typical small install with very small non critical systems there really aren't any compelling reasons to upgrade.My boss and I continue to struggle with the huge amount of hours the DBA and app teams have to spend if we were to upgrade every 18 months our 500+ databases just to keep current when SQL 2008R2 runs just fine.
I know, I know, one must keep up to stay in support and I agree. However, it becomes very expensive to do this.
I'd never upgrade every 18 months. At least not if we weren't in a small shop and doing lots of active development with new features. I tend to want every version to last 5-10 years, leaning to the latter.
If you're on 2008R2, you haven't upgraded for 6 years. I wouldn't necessarily be looking to upgrade now, and I'd say if the systems run, I wouldn't worry too much on support. For those 2005/2008, maybe I'm thinking about upgrading, but this would need to be in conjunction with consolidation or some other move.
For new installs, I wouldn't go backwards.
June 21, 2016 at 1:24 am
I'm confused. It appears you now advocate not upgrading if the SQL version is less than eight years old -- SQL2008R2? Forgive me, but I didn't read that in your initial post about how great SQL 2016 was.
You stated "it's also the most tested and evaluated" and I responded with a Microsft post about how the SQL 2016 instance can crash. You responded with a vague reply about version mismatch. Please correct me if I am wrong:
https://blogs.msdn.microsoft.com/bobsql/2016/06/15/sql-2016install-msvc-patch-required/
My point is SQL 2016 is in no way ready for production, and it is incredibly irresponsible to in any way insinuate that SQL 2016 should be deployed to production.
June 21, 2016 at 5:41 am
Steve Jones - SSC Editor (6/20/2016)
Markus (6/20/2016)
I attended a Microsoft event about SQL 2016 and have read a lot of information about this new release. It does appear this is the best version yet. However, for a typical small install with very small non critical systems there really aren't any compelling reasons to upgrade.My boss and I continue to struggle with the huge amount of hours the DBA and app teams have to spend if we were to upgrade every 18 months our 500+ databases just to keep current when SQL 2008R2 runs just fine.
I know, I know, one must keep up to stay in support and I agree. However, it becomes very expensive to do this.
I'd never upgrade every 18 months. At least not if we weren't in a small shop and doing lots of active development with new features. I tend to want every version to last 5-10 years, leaning to the latter.
If you're on 2008R2, you haven't upgraded for 6 years. I wouldn't necessarily be looking to upgrade now, and I'd say if the systems run, I wouldn't worry too much on support. For those 2005/2008, maybe I'm thinking about upgrading, but this would need to be in conjunction with consolidation or some other move.
For new installs, I wouldn't go backwards.
Understand your point Steve. We got behind with our 2000 systems as the last one was upgraded in 2014. I pushed and pushed folks that owned the 2005 installs here and we now only have two systems left that are targeted to go away by the end of the year. I have been migrating dbs off of 2008 and 2008R2 up to 2012/2014. We have the bulk of all of our stuff in 2008R2.
It would be interesting to see the mix of what people have written in SQL Server versus purchased apps that run on SQL Server. Microsoft can tout SQL2016 all they want but until the vendors of products we have running here support it and a budget is approved and time is allotted no way can we do any upgrades to 2016.
It does seems like there are some minor to mid-minor bugs that show up the first 6 months of a new version so I typically don't like to go with the latest even if the vendor supports it.
June 21, 2016 at 8:14 am
chris 24158 (6/17/2016)
The latest series of posts you enjoy so much from Microsoft says:I can’t emphasize this patch enough. There is a MSVC, runtime library patch needed by SQL Server 2016 and without the patch the SQL Server service can simply terminate (crash.) This may not produce stack dumps and the SQL Server error log often looks like it simply terminates (no logging of shutdown.)
And you recommend this product for production use?
Yeah, so if you want to start using SQL Server 2016, then install the MSVC patch. The problem is within the the VC++ runtime.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
June 21, 2016 at 10:55 am
chris 24158 (6/21/2016)
I'm confused. It appears you now advocate not upgrading if the SQL version is less than eight years old -- SQL2008R2? Forgive me, but I didn't read that in your initial post about how great SQL 2016 was.You stated "it's also the most tested and evaluated" and I responded with a Microsft post about how the SQL 2016 instance can crash. You responded with a vague reply about version mismatch. Please correct me if I am wrong:
https://blogs.msdn.microsoft.com/bobsql/2016/06/15/sql-2016install-msvc-patch-required/
My point is SQL 2016 is in no way ready for production, and it is incredibly irresponsible to in any way insinuate that SQL 2016 should be deployed to production.
Your point is wrong, and it's incorrect to state SQL 2016 isn't ready for production. The issue you refer to is a version upgrade in the C++ DLLs that is needed. This is a timing mismatch. Some systems out there are on older versions of the C++ DLL, which is from 2013 runtime. This needs to be updated. This isn't a SQL Server item, but potentially an issue with the rest of your system.
Could SQL Setup update this? Sure, but that's not the mandate of the SQL Server team. This is a system outside of SQL Server. This has happened in the past with Windows or VS not including an update in their system as they released first, or later, or something else.
If you think this is a big deal, or it's poor writing of the SQL Server code, I'm not sure how to convince you. This is a dependency on other parts of the Windows host. As I mentioned, I haven't had to apply this, some have, some haven't. This isn't a stability issue for SQL unless you refuse to apply the patch. In that case, don't upgrade.
I advocate doing what's best for your business. SQL Server 2016 is the best release to date, in my opinion. That doesn't mean I'm upgrading SQLServerCentral databases. It's not business effective for us and we don't use the newer features. However, if you can, or you benefit from the change, or need to be supported for your business, it's worth looking at.
June 22, 2016 at 2:57 am
Steve Jones - SSC Editor (6/21/2016)
chris 24158 (6/21/2016)
I'm confused. It appears you now advocate not upgrading if the SQL version is less than eight years old -- SQL2008R2? Forgive me, but I didn't read that in your initial post about how great SQL 2016 was.You stated "it's also the most tested and evaluated" and I responded with a Microsft post about how the SQL 2016 instance can crash. You responded with a vague reply about version mismatch. Please correct me if I am wrong:
https://blogs.msdn.microsoft.com/bobsql/2016/06/15/sql-2016install-msvc-patch-required/
My point is SQL 2016 is in no way ready for production, and it is incredibly irresponsible to in any way insinuate that SQL 2016 should be deployed to production.
Your point is wrong, and it's incorrect to state SQL 2016 isn't ready for production. The issue you refer to is a version upgrade in the C++ DLLs that is needed. This is a timing mismatch. Some systems out there are on older versions of the C++ DLL, which is from 2013 runtime. This needs to be updated. This isn't a SQL Server item, but potentially an issue with the rest of your system.
Could SQL Setup update this? Sure, but that's not the mandate of the SQL Server team. This is a system outside of SQL Server. This has happened in the past with Windows or VS not including an update in their system as they released first, or later, or something else.
If you think this is a big deal, or it's poor writing of the SQL Server code, I'm not sure how to convince you. This is a dependency on other parts of the Windows host. As I mentioned, I haven't had to apply this, some have, some haven't. This isn't a stability issue for SQL unless you refuse to apply the patch. In that case, don't upgrade.
I advocate doing what's best for your business. SQL Server 2016 is the best release to date, in my opinion. That doesn't mean I'm upgrading SQLServerCentral databases. It's not business effective for us and we don't use the newer features. However, if you can, or you benefit from the change, or need to be supported for your business, it's worth looking at.
Is the C++ DLL update requested by SQL Server 2016 Setup? I don't see clear info on this. Do I specifically have to refuse/approve the update?
Because, if that's not the case, the unsuspecting admin, who just installs SQL 2016, might get in big trouble.
June 22, 2016 at 9:07 am
I'm not sure where this appears in setup. Certainly it should be quite visible. I think that if you don't have this, setup fails on one of the checks.
Viewing 15 posts - 1 through 15 (of 18 total)
You must be logged in to reply to this topic. Login to reply