Purpose, Pitfalls and Performance Implications Linked Servers Purpose, Pitfalls and Performance Implications http://blog.moserit.com/letting-all-the-air-out-of-linked-servers Linked Servers is an important tool in the DBA tool belt that, like most tools, can be super helpful or cause pain and anguish depending on how they are used. We are going to define what Linked Servers are, how they can be used, some tips on how best to use them, important performance implications, and some real-world query tuning examples.

About Ben Davis Senior Consultant specializing in SQL Server 10 years working with SQL Server Background in infrastructure, virtualization, storage, industrial automation Experience primarily in manufacturing and financial services verticals Resides in Lafayette, IN with wife and three boys LinkedIn - www.linkedin.com/in/bendavisitpro Twitter @BenjaminDavis22 Hobbies – home mechanic, track days, ketogenic (low-carb) lifestyle

What is a linked server? A remote data source that SQL Server can access directly in queries Can be another SQL instance or another OLE DB compliant product such as Oracle, IBM DB2, or Excel SELECT * FROM [SQL2].[DB].[dbo].[table] SQL Server acts as a client to another data source

Why would I use a linked server? Joining local & remote data Not feasible to bring data into local instance Managed/owned by someone else Primary use is by other applications, your use is minor/occasional Change rate is too frequent to consider for ETL Convenience No need to handle joining in the app Skillset present to write the join in T-SQL instead of thru app Network not accessible by app server Inability of SQL client application to connect to another data source type

How to setup 1. Add SQL Server linked server. 2. Add Azure linked server. 3. Add Oracle provider. C:\Users\benjamin.davis2\Downloads\ODAC122010Xcopy_x64\install.bat all c:\oracle odac

Best Practices Bring over as little data as possible If repeated access to the same data, save data in a local temp table for quick access Use should be uncommon, not for regular transactional use. If regular access needed, consider co-locating databases Consider multiple app connections and joining data in the app

MS DTC Microsoft Distributed Transaction Coordinator is required for transactions across instances Need to enable a few things in the Component Services applet Network DTC Access Allow Remote Clients Allow Inbound/Outbound Mutual Authentication or No Authentication Required

MS DTC Configuration

XACT_ABORT Will rollback entire distributed transaction if a run-time error occurs (like a PK constraint failure) when ON If set to OFF (default setting), the individual statement fails but the remainder of statements in the transaction are committed Must be ON for transactions against OLE DB providers, including SQL Server

Support for Mirroring, AGs Until SQL 2016, distributed transactions were not supported for database mirroring or Availability Groups. 2016 allowed this, but only if databases were on different servers 2017 has full support for distributed transactions on Availability Groups no matter the scenario https://docs.microsoft.com/en-us/sql/database-engine/availability-groups/windows/configure-availability-group-for-distributed-transactions

Distributed Transaction Support on SQL Server 2016 DB1 primary DB1 secondary DB2 primary DB2 secondary WSFC Instance 1 WSFC Instance 2 WSFC Instance 3 WSFC Instance 4 SUPPORTED DB1 primary DB1 secondary DB2 primary DB2 secondary WSFC Instance 1 WSFC Instance 2 WSFC Instance 3 NOT SUPPORTED

Tuning example SQL job with linked server references was taking 9.5 hours every day to run. The code had linked server calls and the called code had linked server calls back. Left graph is the linked server source instance wait. Right is the target instance wait. Wait type on source instance was a combination of CPU and OLEDB. Wait type on the target instance was all OLEDB.

Diagram of query EXEC spLinked2017 SQL2017 SQL2016 EXEC spLinked2016 SELECT * FROM Customers…

Tuning example Clustered index scan operation on local table sub-select taking 97% of plan time No index on datetime column in WHERE clause – was doing Clustered Index Scan Added non-clustered index on datetime column Decreased job time from 9.5 to 1.5 hours

Tuning example Next day overall instance wait time after this one change But you think I was satisfied? Heck no! This was too much fun!

Tuning example Step 2 – most tables in stored procedure were accessing remote tables. How about creating a remote version of the stored procedure to call from local SQL Agent? That way, most of the work is done on the instance with the majority of the data on it

Tuning example Step 3 – grab what little remote data there is from the new remote stored procedure into a temp table as it is use repeatedly Step 4 – Instead of a “NOT IN (SELECT column)”, often a LEFT JOIN between tables with “WHERE column IS NULL” is faster.

Tuning result Implementing Steps 2-4 further decreased run time to 16 minutes

http://blog.moserit.com/letting-all-the-air-out-of-linked-servers Ben Davis Senior Consultant BENJAMIN.DAVIS2@MOSERIT.COM 765.412.6838 | mobile 317.596.8022 | office