For some of our environment, we have upgraded our SQL Version to 2017. And what we are doing is that we take SQL 2012 database backup and restore it on SQL 2017 through some automated scripts. And same was the case when these databases were migrated to SQL 2012 from SQL 2008 R2. But the compatibility level of our databases is still of 2008 & 2012 because basically we don’t update compatibility level of database during migration. And the sole reason is the difference of memory architecture among these SQL Versions.
So can anyone help me understanding what can be the possible impacts if we upgrade compatibility of our databases to 2017 from 2012 or 2008? And is there any parallel feature that we’ll have to enable/use in order to have minimal impact of compatibility level change on our environment?
Any help in understanding this would be appreciated.
Adding as an answer as I was running out of space as a comment:
I suspect this question is too broad to be able to provide a comprehensive answer. The best approach might be to simply try the change in a test environment and see what happens. What impact there is will depend largely on your type of workload and what features you're using.
In my experience the biggest catch in these cases when going from a pre-2014 version to a post one is the change to the cardinality estimator. The average query will probably get a little faster but you probably won't notice that because the real problems it solves will have been optimised away. On the other hand there will be a handful of queries that will get slower for you and you'll need to identify these and fix them. As a quick short term fix you can use the hint OPTION (USE HINT ('FORCE_LEGACY_CARDINALITY_ESTIMATION'))
If you're using MERGE statements then there's a risk those might start throwing errors as there's a few known bugs that can appear where the query deadlocks itself, we had to switch to dropping some indexes before merging and re-building them in a big ETL pipeline.
Related
Microsoft SQL Database Engine Tuning Advisor seems to crash constantly for me... on multiple different servers, for multiple different databases, and throughout multiple different versions of SQL server (and DTA)...
I know this is probably a ridiculous question and not of the quality one would expect on stackoverflow :( but has anyone else experienced this?
I was having the same problem, as recently as SQL Server 2014 with Service Pack 2. I had to use a two-step approach to get it working again:
Installed both the latest service pack, and also the latest cumulative update for the service pack. This fixed the issue with Database Engine Tuning Advisor, but it was still crashing for me (see step 2)
I read where "hypothetical indexes" are added to your database when Database Engine Tuning Advisor is running. If it crashes, and does not complete successfully, the hypothetical indexes are not dropped. It was recommended that the hypothetical indexes be dropped from your database.
The combination of installing the latest service packs and cumulative updates, along with dropping the hypothetical indexes, seems to have worked for me.
I've experienced this behavior many times, and the way to fix it was to update my instances to the latest Service packs.
also the first version of SQL 2012 Tuning Advisor was crashing for some reasons, but updating to the latest SP2 has fixed this issue.
side note: plan-cash (a new features in SQL 2012) maybe helpful until you fix this problem permanently.
I was experiencing the same issue when running analysis on a database that contained encrypted stored procedures. I removed the encryption before I captured my profiler trace workload then re-ran the analysis and issue was resolved.
We need to move an enterprise ERP during the upgrade (from 2005 to 2008). I have done some reading regarding the merits of running compatibility mode and I know there are some differences in the SQL estimator running native vs. compatibility mode, but I was wondering if any of you have encountered any performance improvements running a SQL database in compatibility mode on a newer server, i.e. are there any papers or actual experience that suggest that I am going to get better performance running SQL2008 vs. SQL2014 with Compat mode on the database. Do I actually benefit from the new server. We are licensed either way and the ERP is only "guaranteed" on 2008.
I hope to get some feedback for anyone who has run into this problem before. (Compatibility has been around for a long time, so I am sure someone has). Considering that our databases are ~400GB, clustered and SAN'd makes a really real-world test somewhat difficult to really do. Even more-so that the SAN will "prioritise" things - just make the test even more difficult. We all know that SQL 2014 performs better than 2012, but with the poorest of data, it may be the case - hence the general request.
I have never run into any issues with compatibility mode for any version of SQL Server. I also haven't really noticed any performance benefits or drawbacks doing so, but I admit that I haven't done any real timing tests. Usually when I've had to do that, I've upgraded the hardware on the box, so a true comparison is difficult.
Having said that, are you sure that's the way you want to go?
Why not just run a test environment with the database migrated to 2008 and no compatibility? If everything works for you in the test environment, then upgrade directly.
Most SQL Server upgrades are pretty painless, unless you're trying to skip a version or two, which you aren't. Even in failover clusters they aren't that hard as long as you follow the step-by-step procedure from Microsoft.
We have been using sql server 2005 during development and have had no real issues.
Now at the time of the release, it has been suggested we go with SQL server 2008. The installation of it is a bit of a nightmare with all the configuration options and I am sure this will confuse the customers (even with documentation). Powershell etc had to be installed together some other apps before it could install, as well as some windows updates.
Should we just release with SQL server 2005 (if I am not wrong the installation was easier) or would it be better to go with 2008 (and just accept the installation issues)?
JD
If you've developed and tested on 2005, then stay with 2005 to avoid complications, but I would upgrade everything to 2008 at some point.
Based on the information provided, stick to 2005.
Migrate to 2008 after you've been able to run the application in a test environment, thoroughly test it, and check documentation to be sure things line up.
I'm always wwary of making last-minute changes to an application before release. If you decide to switch to SQL 2008 will your team have time to fully regression test your application? I wouldn't just assume that everything will work fine.
If you have the time for full regression testing then the question is, what does SQL 2008 offer to you? Obviously there's no critical technical reason - no function that is in SQL 2008 that isn't in 2005 but which you absolutely must have. Do you think that your customers will care one way or another? Do you have customer that already have 2008 servers and want to leverage that? Will it help your sales to be on the "latest and greatest" version?
Those are just some of the questions to ask.
You can always save the switch to 2008 for a future upgrade.
The install/config issues shouldn't really be the primary focus, because those are one-time things and a well-written guide can address the vast majority of the issues you encounter.
Here's what I would consider making my decision:
Testing - Everything should work fine out of the box, but you're responsible either way. Better the devil you know than the devil you don't. There is a time and a place for upgrades, and right before a release isn't it.
Licensing - Remember that newer software often comes with a higher price tag, and you don't want to be forcing more expensive software on your users without some tangible of benefit.
All in all, I would stay away from upgrading for upgrade's sake. Stick with what you know, until there is a legitimate gain from upgrading.
In a few years time new customers will not be willing to run with SQL Server 2005, so you will have to support SQL Server 2008 at some point.
My experience is it can be very hard to get current customers to update to a new version of a database server when you wish them to take an upgrade of your software, so you will most likely be forced to support SQL Server 2005 for a long time if you allow your customers to use it now.
So do you wish to?
Have some pain now getting SQL Server 2008 working
Or, have the cost of testing and supporting both SQL Server 2008 and SQL Server 2005 every time you do a new release for many years to come
You have to decide if a small delay in releasing is worth it to save the ongoing cost...
This is hard, as time-to-market is often more important in the real world then ongoing maintenance costs. After all if you don’t hit the market window, you have no ongoing maintenance costs!
Will this delay your release? Will it delay it enough to cost money?
I wouldn't worry too much about the installation complication. Your customers will experience the same (or worse) when they have to upgrade to 2008, which they will eventually because you won't stick with 2005 forever. I'd be more concerned about how it affects your project and sales. That would be the trade-off that I would focus on.
Are there any performance benefits of using SQL Server 2008 over SQL Server 2005?
Moving a single database from SQL Server 2005-2008 will not notice a difference really. However, there are new tools and options available in SQL Server 2008 that you MIGHT be able to leverage to provider better performance later on in your application.
One item that comes to mind is filtered indexes. Allowing to create an index on a subset of information.
There may be new features in the engine which execute queries in different ways. This includes changes to the optimiser.
Therefore, the only way you can POSSIBLY tell, is to gather detailed performance data from your application on MSSQL2005, and then repeat the experiment on the same (production-quality) hardware with SQL2008.
You will need to make sure your application works correctly- such a migration can't be done lightly as any change could introduce bugs.
Also, the new version of the database could have performance regressions - which you need to be very careful about.
So in summary:
Benchmark YOUR application on SQL2005
Benchmark it on SQL2008
Use the same production-grade test hardware in your lab both times
Don't run VMs (unless that's what you do in production)
Don't change other parameters
This may not be easy if your application is big / complicated.
Yes. You can compress data in SQL 2008 which can have drastic impact on backup and data transfer times.
Actually SQL2008 has built-in compression that you can enable out of the box which could definately improve performance, but it may depend on what is being returned. I would try this option and benchmark to see if you feel its a worthy change.
Are there good efficiency savings using Sql Server 2005 over Sql Server 2000?
Or does it just have more services etc
Has anyone seen their system work any quicker after making the upgrade?
The surrounding tools such as Analysis Services were substantially rewritten and can get you a variety of wins depending on your requirements. However I don't see a lot of really fundamental changes from 2000 to 2005 in the core database engine.
There are some improvements that may get you better performance in certain situations. SQL2005 has much better support for 64-bit architectures and better table partitioning than SQL2000 (you can partition a table as opposed to making partitioned views). 64-bit support is the most likely to give you a performance win on a large system as it allows you to set up much larger caches.
Apart from those features I don't believe that there is really a large difference. There are probably minor performance tweaks.
The main reason to move from SQL2000 to SQL2005 will be when SQL2000 goes out of support. If you have a running application on SQL2000 there are not a lot of compelling reasons to switch to 2005 while 2000 is still supported by Microsoft.
Data Warehouse systems will get quite a few wins from moving to SQL2005. SSIS, SSAS2005 and SSRS2005 are much better than their SQL2000 counterparts.
2005 provides MVCC - row level versioning essentially - so as a developer there are some efficiencies: less locking to worry about.
I haven't migrated a system from 2000 to 2005 - I've either started with one or the other - so I don't have a comparison of my own. But there is a reasonable chance you will see a perf difference; if not by taking advantage of some of the new features like snapshot isolation, then at least by virtue of the fact that SQL2005's licensing model allows you to go multi-core at no additional licensing cost, and by the fact that SQL2005 has improved memory management.
Things will absolutely run faster with 2005. There were several improvements made to the query optimizer. And now you can create covering indexes so that the included columns only exist at the leaf level and don't have to get sorted. That alone is an enormous improvement and reason enough to upgrade.
SQL 2005 does a better job of working with caching. You used to have to poll SQL 2000 periodically to check for updates to a whole table. Now you can subscribe to a notification when something changes. It also works for queries, tables, and a few other elements.
I would say yes for all of the reasons listed by others, but even if your SQL skills are not that strong and your queries are not that great they will probably run faster on 2005. We moved from 2000 to 2005 and we had some complex queries that we could not get properly optimized in 2000. When we moved to 2005 it ate the queries up! Clearly the optimizer was making much better decisions out of the box.
I would strongly recommend moving to 2005 unless you have no issues with 2000.