SQL Server Linked Server: Kurulum, Güvenlik, Sorgulama ve SQL Server 2025 Değişikliği

Linked server, bir SQL Server instance’ının başka bir veri kaynağını yereldeymiş gibi sorgulamasını ve orada komut çalıştırmasını sağlar: başka bir SQL Server, Azure SQL Managed Instance, Oracle ya da OLE DB sağlayıcısı olan herhangi bir kaynak. SQL Server’ın en eski entegrasyon özelliklerinden biridir ve özellikle raporlama, ERP entegrasyonları ve kademeli migrasyonlarda hâlâ en çok kullanılanlardan biridir.

Aynı zamanda yanlış kurulması kolay bir özelliktir. Varsayılan ayarlar, uzak sunucudaki yetkileri sessizce dağıtan login eşlemeleri oluşturur; four-part name ile yazılmış bir sorgu tüm uzak tabloyu ağ üzerinden çekebilir. SQL Server 2025 ise varsayılan şifreleme davranışını değiştirerek birçok mevcut linked server’ın upgrade sonrasında çalışmamasına yol açtı.

Bu rehberde bir linked server’ın güncel ve desteklenen yöntemle nasıl oluşturulacağını, nasıl güvenli hale getirileceğini, verimli şekilde nasıl sorgulanacağını, uzak table-valued function’ların nasıl çağrılacağını ve SQL Server 2025’e geçmeden önce nelerin kontrol edilmesi gerektiğini anlatıyoruz.

Kısa Cevap: Güvenli ve Hızlı Bir SQL Server Linked Server

Bir linked server şu dört koşul sağlandığında güvenli ve hızlıdır:

• MSOLEDBSQL ve açıkça belirtilmiş Encrypt ayarı kullanılır. SQL Server 2025 bu kararı sizden bekler; aşağıdaki sürüm notlarına bakın.
• Login eşlemesi açık ve en az yetkiyle yapılır. Varsayılan eşlemeyi silin; belirli bir yerel login’i yalnızca entegrasyonun ihtiyaç duyduğu yetkilere sahip özel bir uzak login’e eşleyin ya da Kerberos delegation çalışıyorsa Windows pass-through kullanın.
• Ağır filtreleme uzak tarafta yapılır. Four-part name’in büyük bir tabloyu ağdan çekmesine izin vermek yerine OPENQUERY ya da bir geçici tablo kullanın.
• Her linked server envantere alınır ve upgrade öncesi test edilir. Bunları kullanan job’lar ve raporlar çoğu zaman yalnızca gece bozulur.

Aşağıdaki tablolar güvenlik ve sorgu desenleri için karar tabloları sunar. Her satır Microsoft dokümanı (bağlantılı Microsoft sayfalarında yazan) ya da Saha pratiği (bizim önerimiz, Microsoft gereksinimi değil) olarak etiketlenmiştir.

Linked Server Nedir?

Bir linked server tanımı iki parçadan oluşur: uzak sistemle konuşan sürücü olan OLE DB sağlayıcısı ve işaret ettiği sunucu ya da dosya olan OLE DB veri kaynağı. Tanım oluşturulduktan sonra uzak nesnelere linked_server.veritabani.sema.nesne biçiminde four-part name ile erişir ya da sorguyu OPENQUERY veya EXECUTE ... AT ile uzak tarafa gönderirsiniz.

Linked server’lar SQL Server’da ve bazı kısıtlamalarla Azure SQL Managed Instance’ta kullanılabilir. Azure SQL Database’de yoktur.

Başka Bir SQL Server’a Linked Server Nasıl Oluşturulur?

SSMS’te Server Objects‘i açın, Linked Servers‘a sağ tıklayıp New Linked Server‘ı seçin. Bu pencere sysadmin üyeliği gerektirir ve bazı ayarları gizler; birden fazla sunucuda tekrarlayacağınız işler için script daha iyidir:

USE master;
GO
-- 1. Linked server'ı Microsoft OLE DB Driver (MSOLEDBSQL) ile tanımla
EXEC sys.sp_addlinkedserver
     @server     = N'SALESDB',             -- sorgularda kullanacağınız ad
     @srvproduct = N'',
     @provider   = N'MSOLEDBSQL',
     @datasrc    = N'sqlsales01.corp.local\PROD',
     @provstr    = N'Encrypt=Mandatory;';  -- uzak sunucuda güvenilir bir sertifika gerektirir

-- 2. Tüm yerel login'lere uygulanan varsayılan eşlemeyi kaldır
EXEC sys.sp_droplinkedsrvlogin @rmtsrvname = N'SALESDB', @locallogin = NULL;

-- 3. Yalnızca erişmesi gereken login'i, en az yetkili bir uzak login'e eşle
EXEC sys.sp_addlinkedsrvlogin
     @rmtsrvname  = N'SALESDB',
     @useself     = N'False',
     @locallogin  = N'CORP\svc-reporting',
     @rmtuser     = N'ls_reporting_reader',
     @rmtpassword = N'';

-- 4. Bağlantıyı test et
EXEC sys.sp_testlinkedserver N'SALESDB';

Oracle, PostgreSQL ve Diğer ODBC Kaynaklarına Linked Server

Linked server yalnızca SQL Server ile sınırlı değildir. OLE DB sağlayıcısı olan her veri kaynağı bağlanabilir; Microsoft OLE DB Provider for ODBC (MSDASQL) üzerinden de ODBC sürücüsü olan her kaynak. Kaynak hangisi olursa olsun, sağlayıcı ya da sürücü SQL Server makinesinin kendisine, SQL Server ile aynı bit mimarisinde (güncel her instance için 64-bit) kurulmalı ve SQL Server servis hesabının sağlayıcının kurulu olduğu klasörde okuma ve çalıştırma yetkisi olmalıdır.

Oracle

Oracle için SQL Server makinesine Oracle Provider for OLE DB (OraOLEDB.Oracle) içeren Oracle client’ı kurun ve hedef veritabanı için bir TNS alias tanımlayın. Bu alias, linked server’ın veri kaynağı olur:

EXEC sys.sp_addlinkedserver
     @server     = N'ORAERP',
     @srvproduct = N'Oracle',
     @provider   = N'OraOLEDB.Oracle',
     @datasrc    = N'ERPPROD';            -- tnsnames.ora'daki TNS alias

EXEC sys.sp_droplinkedsrvlogin @rmtsrvname = N'ORAERP', @locallogin = NULL;
EXEC sys.sp_addlinkedsrvlogin
     @rmtsrvname  = N'ORAERP',
     @useself     = N'False',
     @locallogin  = N'CORP\svc-reporting',
     @rmtuser     = N'REPORT_RO',
     @rmtpassword = N'';

-- Oracle'ın kendi SQL lehçesiyle pass-through sorgu
SELECT *
FROM OPENQUERY(ORAERP,
     'SELECT ORDER_ID, ORDER_DATE, TOTAL
      FROM ERP.ORDERS
      WHERE ORDER_DATE >= DATE ''2026-01-01''');

-- Four-part name: catalog boş, Oracle nesne adları genellikle büyük harf
SELECT TOP (10) * FROM ORAERP..ERP.ORDERS;

Oracle’da OPENQUERY genellikle daha iyi seçimdir. Sorgu Oracle’ın kendi lehçesinde çalışır ve filtrelemeyi Oracle yapar. Four-part name’de ise sorguyu çevirmek ve veri tiplerini eşlemek SQL Server’a kalır; Oracle linked server sorunlarının çoğu da burada başlar.

PostgreSQL, MySQL ve Diğer ODBC Kaynakları

Microsoft, PostgreSQL ya da MySQL için bir OLE DB sağlayıcısı sunmaz. Olağan yol, üreticinin ODBC sürücüsünü, örneğin resmi PostgreSQL ODBC sürücüsünü (psqlODBC) ya da MySQL Connector/ODBC’yi MSDASQL üzerinden kullanmaktır. SQL Server makinesinde 64-bit ODBC Data Source Administrator ile bir System DSN oluşturun ve linked server’ı ona yönlendirin:

-- PostgreSQL ODBC sürücüsüyle (64-bit) oluşturulmuş "PG_CRM" System DSN
EXEC sys.sp_addlinkedserver
     @server     = N'PGCRM',
     @srvproduct = N'PostgreSQL',
     @provider   = N'MSDASQL',
     @datasrc    = N'PG_CRM';

-- Login'leri yukarıdaki gibi eşleyin, sonra PostgreSQL'in kendi lehçesiyle sorgulayın
SELECT *
FROM OPENQUERY(PGCRM,
     'SELECT customer_id, email, created_at
      FROM crm.customers
      WHERE created_at >= ''2026-01-01''');

@provstr‘a tam bir ODBC connection string yazmak yerine @datasrc‘ta bir System DSN kullanmayı tercih edin. Microsoft, SQL Server 2022’de (CU 24’ten itibaren) ve SQL Server 2025’te, provider string kullanan MSDASQL linked server’larının sysadmin olmayan login’ler için “Access to the remote server is denied because no login-mapping exists” mesajıyla 7416 hatası verdiği bilinen bir sorunu belgeliyor.

Üçüncü Parti ve Özel Sağlayıcılar

DB2, SAP HANA, bulut veri ambarları ya da şirket içi API’ler gibi sistemler için ticari ya da özel geliştirilmiş OLE DB sağlayıcıları veya ODBC sürücüleri kullanılabilir. SQL Server gerekli arayüzleri uygulayan her OLE DB sağlayıcısıyla çalışır, ancak Microsoft yalnızca kendi varsayılan sağlayıcısıyla test eder; davranış ve destek sağlayıcının üreticisinden gelir. SQL Server’ın bir sağlayıcıyı nasıl kullanacağı, SSMS’te Server Objects → Linked Servers → Providers altında sağlayıcı bazında ayarlanır:

• Allow inprocess: sağlayıcıyı SQL Server sürecinin içinde yükler. Bazı sağlayıcılar buna ihtiyaç duyar; ama varsayılan olarak sağlayıcılar süreç dışında çalışır ve bu, SQL Server’ı sağlayıcıdaki hatalardan korur. Süreç içinde bir sağlayıcı çökmesi tüm instance’ı etkileyeceği için bu seçeneği yalnızca güvendiğiniz ve test ettiğiniz sağlayıcılarda açın.
• Dynamic parameter ve Nested queries: SQL Server’ın parametreli ve iç içe sorguları sağlayıcıya göndermesine izin verir; bu da işin daha fazlasını uzak tarafa taşıyabilir. Yalnızca sağlayıcı destekliyorsa açın.
• Supports ‘Like’ operator: LIKE koşullarının uzak tarafta değerlendirilmesine izin verir.
• Disallow ad hoc access: sağlayıcıya karşı OPENROWSET ve OPENDATASOURCE kullanımını engeller; böylece yalnızca tanımlı linked server’lar üzerinden kullanılabilir.

SQL Server dışındaki kaynaklarda, kaynak bir SQL Server collation’ıyla eşleşen tek bir collation kullanıyorsa collation name sunucu seçeneğini de ayarlayın; böylece metin karşılaştırmaları öngörülebilir davranır.

PolyBase Ne Zaman Daha Uygun?

Oracle, Teradata, MongoDB ya da generic bir ODBC kaynağından yalnızca okuma yapmanız gerekiyorsa PolyBase’i de değerlendirin. SQL Server 2019’dan beri bu kaynakları, linked server ya da sağlayıcı seçenekleri yönetmeden, T-SQL ile external table olarak sunar. Bu kaynaklar için yalnızca okuma desteği vardır ve PolyBase Query Service’in kurulu olması gerekir; generic ODBC, SQL Server 2025 Linux desteğini ekleyene kadar yalnızca Windows’ta çalışıyordu.

SQL Server 2025: Linked Server’ları Bozan Şifreleme Değişikliği

SQL Server 2025’te MSOLEDBSQL, TDS 8.0 ve TLS 1.3 desteği getiren OLE DB sürücüsünün 19. sürümünü kullanır. Bu sürüm bir varsayılanı da değiştirir: linked server Encrypt değerini belirtmiyorsa bağlantı Encrypt=Mandatory ile açılır ve uzak sunucuda geçerli bir sertifika ister. Bu modda self-signed sertifikalar kabul edilmez.

Upgrade sonrasında yıllardır çalışan linked server’lar birden bağlanamaz hale gelebilir. En iyiden en kötüye dört yol var:

• Uzak sunucuya FQDN’iyle eşleşen, CA imzalı bir sertifika kurun ve Encrypt=Mandatory ile devam edin ya da TDS 8.0 için Encrypt=Strict kullanın.
• Linked server’ı provider string’de Encrypt=Optional ile yeniden oluşturun. Bağlanır, ama şifreleme olmadan.
• TrustServerCertificate=Yes ekleyin. Microsoft destekliyor ama sertifika doğrulamasını devre dışı bıraktığı için production’da önermiyor.
• Trace flag 17600’ü açın. Linked server tanımlarını henüz değiştiremiyorsanız OLE DB 18 davranışını korur. Bunu geçici bir çözüm olarak görün.

Linked Server Güvenliği: Login Eşlemeleri

SQL Server uzak tarafa bağlanırken birinin kimliğiyle giriş yapmak zorundadır. SSMS’teki Security sayfası ve sp_addlinkedsrvlogin bunun kim olacağını belirler:

Eşlemede tutulan kimlik bilgileri sunucu tanımında saklanır; bu yüzden uzak login yalnızca entegrasyonun gerçekten ihtiyaç duyduğu yetkilere sahip olmalıdır. Linked server’lar, yetkili kullanıcılarla aynı yetki gözden geçirmesine dahil edilmelidir; bkz. SQL Server güvenlik rehberimiz.

Linked Server Hangi Güvenlik Modelini Kullanmalı?

Tek bir doğru cevap yoktur; doğru model kimin bağlandığına ve istemci ile uzak sunucu arasında kaç ağ atlaması (hop) bulunduğuna bağlıdır. Bu tabloyu başlangıç noktası olarak kullanın:

En az yetki kontrol listesi (Saha pratiği; Microsoft’un en az yetki önerisiyle uyumlu):

• Linked server’ı script ile oluşturun ve kimin çalıştırabileceğini kısıtlayın. T-SQL ile oluşturmak ALTER ANY LINKED SERVER (ya da setupadmin) gerektirir; SSMS penceresi CONTROL SERVER ya da sysadmin ister.
• rpc out‘u yalnızca gerçekten EXECUTE ... AT ya da uzak procedure gerektiren linked server’larda açın.
• Uzak login’e okuduğu nesneler üzerinde SELECT verin. SQL Server 2012 SP1 ve sonrasında bu, optimizer’ın istatistikleri okuması için de yeterlidir.
• Makalenin sonundaki denetim sorgusunu düzenli çalıştırın ve her “tüm login’ler” eşlemesini gözden geçirin.

Linked Server Nasıl Sorgulanır?

Bir linked server’a iş göndermenin üç yolu vardır ve çok farklı davranırlar:

-- 1. Four-part name: planı yerel optimizer kurar ve neyin gönderileceğine o karar verir
SELECT o.OrderID, o.OrderDate, o.Total
FROM SALESDB.Sales.dbo.Orders AS o
WHERE o.OrderDate >= '20260101';

-- 2. OPENQUERY: sorgu metninin tamamı uzak sunucuda çalışır
SELECT *
FROM OPENQUERY(SALESDB,
     'SELECT OrderID, OrderDate, Total
      FROM Sales.dbo.Orders
      WHERE OrderDate >= ''20260101''');

-- 3. EXECUTE ... AT: uzak sunucuda herhangi bir batch çalıştırır ("rpc out" seçeneği gerekir)
EXEC ('SELECT OrderID, Total FROM Sales.dbo.Orders WHERE CustomerID = ?', 42) AT SALESDB;

• Four-part name en okunaklı yöntemdir ve yerel tablolarla join edilebilir. İşin ne kadarının uzakta yapılacağına SQL Server karar verir; karmaşık koşullarda ya da join’lerde beklediğinizden çok daha fazla satır çekebilir.
• OPENQUERY uzak sunucuda bir pass-through sorgu çalıştırır ve yalnızca ilk sonuç kümesini döndürür. Değişken kabul etmez ve sorgu metni en fazla 8 KB olabilir. Bir değer geçirmek için ifadenin tamamını dinamik SQL olarak oluşturup sp_executesql ile çalıştırın.
• EXECUTE ... AT parametreleri ? yer tutucularıyla kabul eder ve DDL ile stored procedure’ler dahil her türlü batch’i çalıştırabilir. Linked server’da rpc out‘un açık olmasını gerektirir.

Linked Server Üzerinden Table-Valued Function Çağırma

Sık karşılaşılan bir sürpriz, uzak table-valued function’ların four-part name ile çağrılamamasıdır. SELECT * FROM SALESDB.Sales.dbo.fn_CustomerOrders(42) şu hatayı verir:

Çözüm, fonksiyonu uzak sunucuda çalıştırıp yalnızca sonucunu geri almaktır:

-- Sabit parametre: OPENQUERY
SELECT *
FROM OPENQUERY(SALESDB, 'SELECT * FROM Sales.dbo.fn_CustomerOrders(42)');

-- Değişken parametre: ? yer tutuculu EXECUTE ... AT
DECLARE @CustomerID int = 42;

CREATE TABLE #orders (OrderID int, OrderDate date, Total decimal(18,2));

INSERT INTO #orders (OrderID, OrderDate, Total)
EXEC ('SELECT OrderID, OrderDate, Total FROM Sales.dbo.fn_CustomerOrders(?)', @CustomerID) AT SALESDB;

SELECT * FROM #orders;

INSERT ... EXEC ... AT bir transaction içinde çalışır. Linked server’ın remote proc transaction promotion seçeneği varsayılan olarak açık olduğundan SQL Server bunu MSDTC üzerinden dağıtık bir transaction’a yükseltmeye çalışabilir. Sunucular arasında MSDTC yapılandırılmamışsa ve dağıtık transaction’a ihtiyacınız yoksa bu linked server için seçeneği kapatın.

Linked Server Performansı

Yavaş linked server sorgularının çoğu tek bir nedene dayanır: ağdan çok fazla satır geçmesi. Birkaç kural yardımcı olur:

• Filtrelemeyi uzak tarafta yapın. Four-part name ile yazılmış bir sorgu yavaşsa execution plan’a bakın. Milyonlarca satır döndüren bir Remote Query ya da Remote Scan operatörü, filtrenin gönderilmediğini gösterir. Filtrelemeyi uzak sunucunun yapması için sorguyu OPENQUERY ile yeniden yazın.
• Büyük bir yerel tabloyu büyük bir uzak tabloya doğrudan join etmeyin. Önce küçük, filtrelenmiş uzak kümeyi geçici bir tabloya alın, gerekiyorsa index ekleyin, sonra yerelde join edin.
• Uzak login’in istatistiklere erişebildiğinden emin olun. Optimizer satır sayılarını tahmin etmek için uzak tablonun istatistiklerini kullanır. SQL Server 2012 SP1’den beri bunları okumak için SELECT yetkisi yeterlidir; daha azıyla planlar kötüleşebilir.
• collation compatible‘ı yalnızca gerçekten doğruysa açın. İki sunucu gerçekten aynı collation’ı kullanıyorsa karakter karşılaştırmalarının uzak tarafa gönderilmesini sağlar. Yanlış ayarlanırsa hatalı sonuç döndürür.
• Timeout’ları ayarlayın. connect timeout ve query timeout, takılan bir uzak sunucunun yerel session’ları ve lock’ları süresiz tutmasını engeller.

OPENQUERY mi Four-Part Name mi: Hangi Desen Daha Hızlı?

Hiçbiri her zaman daha hızlı değildir. Farkları işin nerede yapıldığıdır; bu da ağdan kaç satır geçeceğini belirler:

OPENQUERY‘ye bir değişken geçirmek için ifade dinamik SQL olarak kurulmalıdır:

-- OPENQUERY'ye değer geçirme: ifadeyi dinamik SQL olarak kurun.
-- Değer tiplidir (date), sabit formata çevrilir ve serbest metin olarak eklenmez.
DECLARE @from date = '2026-01-01';
DECLARE @sql nvarchar(max) =
    N'SELECT * FROM OPENQUERY(SALESDB, ''SELECT OrderID, Total FROM Sales.dbo.Orders WHERE OrderDate >= '''''
    + CONVERT(char(8), @from, 112) + N''''''')';
EXEC sys.sp_executesql @sql;

Kontrol etmeye değer diğer performans tuzakları (hepsi Saha pratiği): geniş uzak tablolarda SELECT *, iki sunucunun farklı collation kullandığı karakter karşılaştırmaları ve filtre kolonunda uzak index eksikliği. Sonuncusu için OPENQUERY uzak taramayı düzeltmez, çünkü sorguyu yine uzak sunucu çalıştırır.

Bilinmesi Gereken Linked Server Seçenekleri

EXEC sys.sp_serveroption N'SALESDB', 'rpc out', 'true';
EXEC sys.sp_serveroption N'SALESDB', 'query timeout', '600';

Sürüm Notları

Linked Server’larınızı Denetleyin

Linked server’lar yıllar içinde birikir ve yarısının neden var olduğunu kimse hatırlamaz. Bu sorgu her birini sağlayıcısı, hedefi ve login eşlemeleriyle listeler. local_principal_id değerinin 0 olması, eşlemenin tüm login’lere uygulandığı anlamına gelir:

SELECT s.name                         AS linked_server,
       s.provider,
       s.data_source,
       s.provider_string,
       s.is_rpc_out_enabled,
       COALESCE(sp.name, '(all logins)') AS local_login,
       ll.uses_self_credential,
       ll.remote_name
FROM sys.servers AS s
LEFT JOIN sys.linked_logins     AS ll ON ll.server_id   = s.server_id
LEFT JOIN sys.server_principals AS sp ON sp.principal_id = ll.local_principal_id
WHERE s.is_linked = 1
ORDER BY s.name, local_login;

Üç şeye bakın: hâlâ SQLNCLI ya da SQLOLEDB kullanan sağlayıcılar, güçlü uzak login’lere yapılmış “tüm login’ler” eşlemeleri ve artık var olmayan sunuculara işaret eden linked server’lar. Linked server’ların sunucu seviyesinde nesneler olduğunu da unutmayın. Bir availability group‘ta veritabanlarıyla birlikte failover yapmazlar; bu yüzden her replikada oluşturun.

Kaynaklar ve Gözden Geçirme Tarihi

Bu makale 19 Ekim 2026 tarihinde aşağıdaki Microsoft Learn sayfalarına karşı kontrol edildi. Saha pratiği olarak etiketlenen ifadeler bizim önerilerimizdir ve bu sayfalarda yazmaz.

• Linked servers (Database Engine)
• Create linked servers
• sp_addlinkedsrvlogin
• sp_addlinkedserver
• OPENQUERY