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
Related
I have two sql servers
Windows Server 2008R2 SQL Server 2012
Windows Server 2012R2 SQL Server 2016
I want to mirror one of the databases to the other.
Will it work on different sql versions or cause problems?
The summary is-
The principal and mirror server instances must be running on the same version of SQL Server. While it is possible for the mirror server to have a higher version of SQL Server, this configuration is only recommended during a carefully planned upgrade process. In such a configuration, you run the risk of an automatic failover, in which data movement is automatically suspended because data cannot move to a lower version of SQL Server.
For more details, please visit Here
Will it work on different SQL Versions or cause problems?
Yes, but it will work only when Primary is Lower and Secondary is Higher version, as it already confirmed by MkRabbani, you need to plan it accordingly.
Consider, by any chance if fail-over happened the database cannot be reverted back (by fail-over again). So, it's possible but depends on your scenario how do you want use Mirroring, Log Shipping etc.. as all work in same manner (always lower to higher version possible, but not higher to lower).
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.
Is it possible to create Transactional Replication setup between 2017 Enterprise edition to 2005 Standard edition in MS SQL Server?
I heard that it is possible through scripts, is it right?
Publisher and Subscriber needs to be within 2 versions and Distributor should be higher than or equal to subscriber. You can always configure with a Subscriber that is beyond 2 versions from Publisher through T-SQL scripts and it might work. But it is not supported by Microsoft which means you are on your own if there is anything that blocks you.
As you called out, you should be able to configure replication between 2017 and 2008R2 but your 2008R2 server would miss all the improvements and updates we made to the internal stored procedures and metadata related to replication. Though most of these changes should be backward compatible, some of these might not work as expected if your running them in unsupported configurations.
Has anyone here moved the database underlying a SP 2010 install from one database instance to another (same data, just hosted in another instance)?
For example. we just want to move the database to a diffrerent machine.
In addition, has anyone moved SP 2010 from using SQL Express to a higher version of SQL Server? I would like to run some proof of concept tests with SQL Express, and if all goes well, then move to SQL Standard or Enterprise.
Cheers,
Daniel
Check out the following article:
http://technet.microsoft.com/en-us/library/cc512725.aspx
I don't think you'll run into any problems, just make sure you aren't going backwards in versions between databases. Backing up a database in SQL Server 2008 and restoring in 2005 isn't easy.
I've never done this with SharePoint, but I believe it lets you specify the location of the configuration database. Then you just need to match the user permissions.
The TechNet article "Move All Databases (SharePoint 2010)" is your main guide.
Note that this article contains the following warning:
The new database server must be running the same version of Windows
Server and Microsoft SQL Server as the existing database server.
This in NOT true!
Both from my own experience in migrating SharePoint databases and talks I've had with Microsoft Primary Field Engineering, I can say this method also works when SQL Server versions differ. But only if you upgrade to higher SQL Server versions (i.e. SQL Server 2005 to SQL Server 2008 R2). I was told this scenario is also fully supported by Microsoft.
Also, don't forget to update the database compatibility level for the migrated databases. This should future-proof your databases and enable advanced SQL Server optimization.
What is the best way to use SQL Server 2008 as a development database, but ensure that the database is compatible with SQL Server 2005?
This can be done via SQL Enterprise Manager or like this:
ALTER DATABASE <database>
SET COMPATIBILITY_LEVEL = { 80 | 90 | 100 }
Use 90 for 2005 compatibility.
This replaces the functionality used for previous releases, the stored procedure sp_dbcmptlevel.
You can set the database compatibility level, but there is no guarantee that this will cover all your bases. For example the new data types will be available on the SQL 2008 system, but they won't be available on the SQL 2005 server.
The only way to guarantee that everything will work from Dev to Prod is to put SQL 2005 in development.
Don't forget that there are also behavioral differences between the two versions, and something on 2008 may perform differently (and insufficiently) than 2005 all other things equal - this will obviously depend on a lot of factors about your data and application.
You're better off developing against the lowest common denominator and testing against the newer versions.