Change compatibility level of all databases after an upgrade

You make an upgrade to SQL 2016 from SQL 2014, one thing you have to watch out for is the compatibility levels of the upgraded databases. By default, all the databases will be at the compatibility level of the older version. They need to be changed manually to make use of all the new features of the upgraded version. Below is a script that can take care of that part for you!


set quoted_identifier off
declare @procname varchar(100)
declare @string varchar(1000)
declare cursor1 cursor for
select name from sys.databases where compatibility_level=120
open cursor1
fetch next from cursor1 into @procname
while (@@fetch_status = 0)
begin
select @string="alter database "+@procname +" set compatibility_level = 130"
print @string
fetch next from cursor1 into @procname
end
close cursor1

deallocate cursor1

Database Shrink file Error - 'Could not locate file' error

When you try to shrink a database log file, you might encounter the below error message:

Could not locate file 'dbname_log' for database 'DBNAME' in sys.database_files. The file either does not exist, or was dropped. 

This happens if the logical file name does not match the file name in sys.master_files. To verify that there is a file name mismatch, you can run the below commands:

Command 1:

use dbname

go

sp_helpfile

go

Command 2:

select name from sys.master_files where database_id = db_id('dbname')

You will see that the log file name is different in each one. Get the name of the log file from the second command (that appears different) and we will use that as 'oldfilename' in the command below

To fix this, we just have to run the 'alter db' command by specifying the correct file name (referred to as 'newfilename', should be something like ‘dbname_log’) as shown below:

USE [DBANAME]

GO

ALTER DATABASE [DBNAME] MODIFY FILE (NAME=N'oldfilename',NEWNAME=N'newfilename')

GO

If that didn’t do the trick try running the below command using ‘new filename’ in both places:

USE [DBANAME]

GO

ALTER DATABASE [DBNAME] MODIFY FILE (NAME=N'newfilename',NEWNAME=N'newfilename')

GO

SQL Agent does not come online in Failover Cluster Manager after upgrade to SQL 2016

I recently upgraded SQL 2014 SQL Instance in a cluster to SQL 2016. After the upgrade, the SQL Agent fails to come online and the Event Viewer shows the below error messages:

SQLServerAgent could not be started (reason: Unable to connect to server 'ServerName\InstanceName'; SQLServerAgent cannot start).

The description for Event ID 17052 from source MSSQLSERVER cannot be found. Either the component that raises this event is not installed on your local computer or the installation is corrupted. You can install or repair the component on the local computer.

If the event originated on another computer, the display information had to be saved with the event.

The following information was included with the event: 

Severity: 16 Error:-1, OS: -1 [Microsoft][ODBC Driver 13 for SQL Server]SQL Server Network Interfaces: Error Locating Server/Instance Specified [xFFFFFFFF]. 

The error message is related to the ODBC driver 13 that is not compatible with SQL 2016. I had to upgrade that to ODBC 13.1 from the url below. Once the upgrade is done, the SQL Agent service will come back online.

https://support.microsoft.com/en-nz/help/3185365/sql-server-2016-agent-fails-to-start-or-failed-to-retrieve-data-error-when-you-try-to-read-error-log-from-ssms-2016

'VIEW SERVER STATE permission was denied on object 'server''error message

We had a developer encounter this error when trying to perform a right-click on a table and selecting 'Select top 1000 rows'. SSMS would eventually display the results, but the pop-up error message is annoying.

An exception occurred while executing a Transact-SQL statement or batch. (Microsoft.SqlServer.ConnectionInfo)

------------------------------

ADDITIONAL INFORMATION:

VIEW SERVER STATE permission was denied on object 'server', database 'master'. (Microsoft SQL Server, Error: 300)

I was able to identify the root cause as the version of SSMS being used. In this case, the developer was trying to access SQL 2014 Instance using a SQL 2012 SSMS. The issue has gone away when SQL 2014 SSMS was used.