I have a database which was upgraded from 2000 to 2005. Is there any issue using sp_dbcmptlevel to change compatibility level to 90. Will this cause any issues with old queries or stored procedures
Did you run the SQL Server upgrade adviser on the old database? It will tell you if there is any obvious problems. Be sure to test on a development database.
Here is the tool
http://www.microsoft.com/downloads/details.aspx?FamilyID=1470e86b-7e05-4322-a677-95ab44f12d75&displaylang=en
Related
I am successfully doing a daily restore of a backup from an earlier version onto MS SQL 2017 using T-SQL.
However during the restore the database gets upgraded to the current version.
This is a problem as I wish to modify the database and then do a backup which then gets transferred and restored to another system which is using the same earlier version of MS SQL.
Is it possible to run the RESTORE without the database getting upgraded?
Have been looking through T-SQL documentation and not found this referred to.
The T-SQL code I am using is:
USE master
GO
ALTER DATABASE Polly SET SINGLE_USER
with ROLLBACK IMMEDIATE
GO
RESTORE DATABASE Polly FROM DISK = 'C:\data\Polly.bak';
GO
USE Polly
DELETE FROM SytLog;
GO
ALTER DATABASE Polly SET MULTI_USER
GO
If anyone has general improvements to above I am happy for suggestions.
When the above runs I get:
Database 'Polly' running the upgrade step from version 782 to version 801.
...
Database 'Polly' running the upgrade step from version 868 to version 869.
Would like to see no upgrade steps, but only if database still usable.
When the above runs I get: Database 'Polly' running the upgrade step
from version 782 to version 801. ... Database 'Polly' running the
upgrade step from version 868 to version 869.
Would like to see no upgrade steps, but only if database still usable.
This is not possible. Every version of SQL Server has its data and log files structure that differs between server versions. And if you restore or attach database from lower version db files are one-way updated to have a structure that the current version of SQL Server needs.
It's impossible to not upgrade because the current version of server needs that new structure for db files.
All speculations around compatibility level / read_only property will not help at all, current server will never run with files that are not of the structure it needs.
In case of readonly database its files will be upgrade but the database will remain readonly.
Compatibility level has nothing to do with database version (version of db files) at all. It just tell to server what version of query optimizer should be used, what legacy syntax can still be parsed, etc.
No, this isn't possible. Once a database is attached to a newer version of SQL Server, you can't move it back to older. The only option in this case is to export/import the data. If you need to modify the database and move it back to the older server, you need to install a server with the same old version and do the restores there!
Microsoft documentation states:
If you restore a SQL Server 2005 (9.x) or higher database to SQL Server 2017, the database is automatically upgraded.
Although I would try in case of desperate need to create read-only database and restore it.
But this is kind of black magic not directly supported by vendor.
The compatibility level is important.
Even when the compatibility level of the database needs to be changed, under certain conditions the backup can’t be simply restored.
Restoring a database backup created on a SQL Server 2008
R2 to a SQL Server 2012 instance goes smoothly, but if a SQL Server
2000 backup is tried to be restored on a SQL Server 2012 you cannot
directly do it.
Reading official docs about STRING_SPLIT function, at the begining of the doc there is a note:
Note
The STRING_SPLIT function is available only under compatibility level
130 and above. If your database compatibility level is lower than 130,
SQL Server will not be able to find and execute STRING_SPLIT function.
To change the compatibility level of a database, refer to View or
Change the Compatibility Level of a Database. Note that compatibility
level 120 might be default even in new Azure SQL Database.
So, what does compatibility level mean?
Compatibility Level refers to the way SQL Server operates in relation to a specific version of SQL Server.
Let's say for example, you have an application running well on SQL Server 2012, but you need to upgrade to SQL Server 2019 because support is ending soon. Everything runs great on SQL Server 2012 and the application has not been updated in many years. So, it's unclear how it might perform running on SQL Server 2019, or if it'll even work at all.
To ease the transition when you migrate to SQL Server 2019, you could consider leaving the database in SQL Server 2012 compatibility level, to avoid any unforeseen performance issues that may be introduced by the way the SQL engine and optimizer work in SQL Server 2019. Essentially, to the application, it's as if you're still running SQL Server 2012.
Now, the downside is that you can also not take advantage of the newer features that have been introduced since SQL Server 2012, such as STRING_SPLIT.
Recently, we migrated the servers from SQL Server 2012 to 2016. Without any changes, a few of the queries got performance degraded.
If I run the query in SQL Server 2012, it takes 10 seconds, but the same query takes 50+min in SQL Server 2016.
If I updated the SQL Server 2016 database with Legacy CE = ON then I am able to get the results very quickly as same as 2012. But I believe it's not recommended to use Legacy CE ON in SQL Server 2016.
ALTER DATABASE SCOPED CONFIGURATION SET
LEGACY_CARDINALITY_ESTIMATION = ON;
I also updated the statistics of all tables, even thought I did get any improvement in execution.
So, Is this related to DB configuration issue (or) really do I need to update the query?
I am not sure, which configuration details I need to check. Could you please suggest anything?
Thanks advance..
solution: Link1 /
Link2
Route cause : CARDINALITY_ESTIMATION
Thanks to all.
We are updating several SQL Server 2008R2 instances to SQL Server 2012 SP3 CU2. I know that the database versions will be changed from 100 to 110 during this process (e.g. once finished, the databases can no longer be moved back to a 2008R2 instance).
Does this change to the databases occur during the upgrade itself or the first time that the databases are brought online when the server restarts?
SQL server keeps track of version in two ways. First, your SQL Server instance has a version (for example SQL Server 2008 R2 is 10, followed by some decimals to keep track of patches).
Your databases are a separate version, known as a Compatibility Level. If you upgrade your instance, your databases will not be upgraded until you choose to do so. That does not mean there will not be an impact, however it does mean those databases can remain in their old version. Your example of 100 and 110 are both Compatibility Level.
Please see changing Compatibility on MSDN here: https://msdn.microsoft.com/en-us/library/bb510680.aspx
I recently changed my compatibility mode of my sql server 2005 form 2000 to 2005.
Is there a utility that can scan my sp and functions and tell me if I have any compatibility issues?
I am not sure if it works from inside sql 2005; but if you still have a sql 2000 server then MS have an upgrade advisor that will report on your code. If you don't scripting out all the objects and trying to run them back into a new database set as sql 2005 mode is a fairly good way to test the migration.
Depending on your application be careful just switching there are syntax differences and connection options that changed between 2000/5 beyond just stored procedure changes. If your application runs sql queries natively (not sp's) then the application may have compatibility issues beyond just the internal database code.