Month: June 2016

SQL Server: Create a linked server from an on-premise SQL Server* to SQL Azure

by
  • SQL Server 2008 onwards

The use of SQL Server’s sp_addlinkedserver can be a little arcane. I recently needed to connect from an on-premise SQL Server to SQL Azure for the purpose of querying and downloading data to a reporting server, and there a couple of things to note.

One is that you should ensure that data is encrypted on the wire (* and also when connecting to remote servers from SSMS).

 

The other is that you have to may specify the server name as a DNS name (depending on the client connection library you are using). This is the case if you receive this error message:

“Server name cannot be determined.  It must appear as the first segment of the server’s dns name (servername.database.windows.net).  Some libraries do not send the server name, in which case the server name must be included as part of the user name (username@servername).  In addition, if both formats are used, the server names must match. “

Here’s the working TSQL script I used:

 

— If linked server already exists, drop it and any associated logins.

begin try

    exec sp_dropserver ‘LocalLinkedServername’, ‘droplogins’

end try

begin catch

end catch

 

— Create the linked server: 

EXEC sp_addlinkedserver

    @server     = ‘LocalLinkedServername’,

    @srvproduct = N’Any’,

    @provider   = ‘SQLNCLI’,

    @datasrc    = ‘??????????.database.windows.net’, — Azure server name

    @location   = ”,

    @provstr    = N’Encrypt=yes;’,       — * Important!

    @catalog    = ‘RemoteDatabaseName’;  — remote(Azure) database name

go

 

— Create the login credentials for the linked server 

EXEC sp_addlinkedsrvlogin

    @rmtsrvname  = ‘LocalLinkedServername’,

    @useself     = ‘false’,

    @rmtuser     = ‘remotesqlusername@??????????.database.windows.net’,

    @rmtpassword = ‘remote password’;

go

 

 

EXEC sp_serveroption ‘LocalLinkedServername’, ‘rpc out’, ‘true’;

go

 

— Don’t elevate to distributed transactions

EXEC sp_serveroption ‘LocalLinkedServername’, ‘remote proc transaction promotion’, ‘false’;

go

 

—- Finally, check you can access remote data via your linked server:

select top 100 *

from [LocalLinkedServerName].[RemoteDatabaseName].[RemoteSchemaName].[RemoteTableName];

go

 

 

 

Another issue you might run into is if you have SQL Database auditing turned on in Azure, Azure wants all connections to be from a secure connection string, and if you run the above script from certain versions of SSMS (I believe SQL Server 2012 and below but not verified) then you might get an error saying only connections with secure connection string are allowed (despite a secure connection being specified). The fix is easy, change

myServerName.database.windows.net

to

myServerName.database.secure.windows.net

Keep in mind that prior to SQL Server 2012 SP1, remote server statistics won’t be able to be used to determine query plans unless admin credentials are used (not a good idea!). Prior to SQL Server 2012 SP1 there is a workaround shown here: SQL Server Linked Servers and Remote Statistics

 

Refs.:

TOP 3 PERFORMANCE KILLERS FOR LINKED SERVER QUERIES

SQL Server and SQL Azure: Clear Plan Cache

by

For on-premise SQL Servers you can run

dbcc freeproccache

which clears the entire server cache (provided you have the ALTER SERVER STATE permission). Many online resources and SQL Server Books Online give scary warnings about running this, but running DBCC FREEPROCCACHE will cause very few problems, even on a busy OLTP system. It will cause a small CPU spike for a few seconds as query plans get recompiled. It can be a useful tool when base-lining expensive queries or stored procedures.

If that’s not selective enough, you can free the cached plans for a single database using an undocumented DBCC command, FLUSHPROCINDB:

-- Flush all plans from the plan cache for a single database  

declare @dbid int;

select @dbid = dbid from master.dbo.sysdatabases where name = 'MyDatabaseName';



dbcc flushprocindb(@dbid);

If you want to remove a single plan from the cache:

-- Get the plan handle (varbinary(64)) for a cached query plan

select 

    cp.plan_handle, 

    st.text

from 

    sys.dm_exec_cached_plans cp 

    cross apply sys.dm_exec_sql_text(plan_handle) st

where 

    text LIKE N'%GetJournal%';



-- Remove a specific plan from the cache using its plan handle

dbcc freeproccache (0x060050000C267C1030CE4EC70300000001000000000000000000000000000000000000000000000000000000);

DBCC FREEPROCCACHE is not supported in SQL Azure as that wouldn’t be practical in a multi-tenanted database environment. SQL Azure (and SQL Server 2016) has introduced a new mechanism for clearing the query plans for a single database:

ALTER DATABASE SCOPED CONFIGURATION CLEAR PROCEDURE_CACHE;

ALTER DATABASE SCOPED CONFIGURATION

This statement enables the configuration of a number of database configuration settings at the individual database level, independent of these settings for any other database. This statement is available in both SQL Database V12 [SQL Azure] and in SQL Server 2016. These options are:

  • Clear procedure cache.

  • Set the MAXDOP parameter to an arbitrary value (1,2, …) for the primary database based on what works best for that particular database and set a different value (e.g. 0) for all secondary database used (e.g. for reporting queries).

  • Set the query optimizer cardinality estimation model independent of the database to compatibility level.

  • Enable or disable parameter sniffing at the database level.

  • Enable or disable query optimization hotfixes at the database level.

Database Scoped Configuration