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.
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.
I know the advantages of upgrading from sql server 2005 to sql server 2008, but upper management could care less about t-sql debugging, intellisense, the merge statment, etc..., so what are some features in sql server 2008 that upper management might actually find worth while.
I suppose you could try showing them some of Microsoft's case studies that have some relevance to your company. It might give them some warm fuzzies to see that someone else has done something similar.
http://www.microsoft.com/sqlserver/2008/en/us/case-studies.aspx
Honestly, if the level of management that is deciding which database technology to buy doesn't understand t-sql debugging and intellisense then your company has the wrong people making technical decisions.
Transparent database encryption - even if the backup files get stolen (or the entire data files) the database cannot be read. Reduces the cost of data loss and embarrassing media attention.
SQL Audit - see who's doing what with the data with no 3rd party tools necessary
Policy-based management - reduce the amount of time needed to ensure the servers adhere to a defined policy.
You can definitly get the product released faster.
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.
I'm starting a new project here (Windows Forms). What's the best option today for a small (free as in beer) DBMS?
I've used SQL Server Express on the past projects, but time and time again I hear people saying that the product from Oracle is faster and more powerful.
It will be used in a small company (around 20 users) and will not reach the 4 GB limit any time soon :)
I don't want to start a flame war on my first post, so please point me to some link showing a good (and actual) comparison between the 2 products, if possible.
PS: I've heard about IBM DB2 Express too, but I coudn't find any information about it. (Marketing material from IBM doesn't count :) )
I would go for the SQL Server Express solution, unless you absolutely have to use a feature in Oracle that SQL Server does not have and you have no usable workaround.
Example of Oracle's strengths:
Analytical Functions in Oracle ROCK!
PL/SQL is better than T-SQL.
If you're going to scale up the system to 1,000's of users all updating the same small dataset
You scale upto multi-TB databases,
You need to scale to need big numbers of CPU's in your server (over 8).
need instant failover (RAC)
you really cannot afford to lose a transaction.
Maybe you can tell, I'm a big Oracle fan! But I think that Oracle Express is a commercial reaction to SQL Server Express and I don't think Oracle really deep deep down likes it.
You know with SQL Server that there is an upgrade path (SQL Server 2008 is soon) plus service packs.
SQL Express is also more "install and forget" than Oracle.
and it will integrate better with your IDE (if your using .NET)
In terms of speed, both are going to be lighting quick with such a small dataset size.
It would be hard to argue either way given the needs you outlined, that either would shine over the other.
What I will say is this:
You say you are already familar with SSExpress, then that is a good reason to stick with it
IMHO the tools with SSExpress are superior and easier to use than the Oracle equivalent
That said, I have much more experience with SS than Oracle so YMMV.
Sorry, no link, but one advice. Because we support Oracle and SQL Server, I know that getting fixes for the 'normal' Oracle database, is not something what I call fun. You have to pay for it, and if you have no tool which updates your Oracle system for you, it's a pain in the a.., if you ask me. Check out how the Oracle XE is supported with updates/fixes. I don't know, I only use the 'normal' Oracle (Developer) database.
I think it's great to rethink things every once in a while and that it's very smart to consider alternative products when you are at a junction to do so.
If you are comfortable optimizing systems and are dba level in skills, I'd consider PostgreSQL. I do not consider myself a dba and have middling database skills and find SQL Server Express extremely easy to use. Also, I've had products exceed the limits of SQL Server Express - the transition to SQL Server Standard/Enterprise is seemless.
I realize that this doesn't matter at a technical level, but Larry Ellison buys jets and prostitutes with his profit. Bill Gates is solving problems of immense importance to humanity with his. All things being equal, I always prefer to give my money to Bill Gates.
Is this any use:
https://web.archive.org/web/1/http://downloads.techrepublic%2ecom%2ecom/5138-9592-6028761.html
NB Registration is required
Both of KiwiBastard's points are very good and I completely agree with him.
If you really want a free alternative that is similar to MS SQL and supports growth should you need it, you could have a look at MySQL or PostgreSQL. SQLite also seems a good choice.
Surely you can afford an old Linux server if you work in a company with 20 employees.
100% SQL Express, more easy to install and maintain than Oracle.
IMHO the major problem with SQL Server, has for a long time been, no multi-version read consistency. Fortunately this has been corrected since SQL Server 2005 with the snapshot isolation level.
If your looking for a good RDBMS for a small project requring minimal knowledge for maintenance, SQL Server Express Edition is a good pick. The SQL Server Express Edition UI is much easier to understand than RMAN or the "easier"-to-use backup scripts included with Oracle Database XE which requires offlining your database.
Oracle Database XE is on my *** list. They recently released an ODBC driver for Linux that wasn't compiled properly (ld returns missing symbols for required ODBC functions) to be at all usable (10.2.0.4). With this kind of lack of attention to any reasonable amount of QA even for a 'free' product I would think twice about going down that road.
For DB2 Express-C see:
"DB2 Express-C™ is the free version of one of the most advanced
database management systems in the world. Why pay when you can have
all you need for free? DB2 Express-C is free to develop, deploy and
distribute.
It is a fast, secure, reliable, and amazingly scalable dataserver,
ideal for most startups and small/medium sized businesses. DB2
Express-C 9.7 is available on Linux, Unix, Windows, and now Mac OS X
as well! It also enables developers to easily handle XML through the
native storage technology called pureXML™. Whether you develop in
Java, .Net, Ruby, Python, Perl or pretty much any other programming
language out there, DB2 can be your technological advantage."