Nuta
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zalogować się lub zmienić katalogi.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
Dotyczy:
SQL ServerAzure SQL Managed Instance
Serwery połączone umożliwiają aparatowi bazy danych programu SQL Server i usłudze Azure SQL Managed Instance odczytywanie danych ze zdalnych źródeł danych i wykonywanie poleceń względem zdalnych serwerów baz danych (na przykład źródeł danych OLE DB) poza wystąpieniem programu SQL Server. Zazwyczaj połączone serwery są skonfigurowane tak, aby umożliwić aparatowi bazy danych wykonywanie instrukcji Transact-SQL, która zawiera tabele w innym wystąpieniu programu SQL Server lub innym produkcie bazy danych, takim jak Oracle. Wiele typów źródeł danych OLE DB można skonfigurować jako serwery połączone, w tym dostawców baz danych innych firm i usługi Azure Cosmos DB.
Uwaga / Notatka
Połączone serwery są dostępne w usługach SQL Server i Azure SQL Managed Instance (z pewnymi ograniczeniami). Połączone serwery nie są dostępne w usłudze Azure SQL Database.
Kiedy używać serwerów połączonych?
Serwery połączone umożliwiają implementowanie rozproszonych baz danych, które mogą pobierać i aktualizować dane w innych bazach danych. Serwery połączone to dobre rozwiązanie w scenariuszach, w których należy zaimplementować fragmentowanie bazy danych bez konieczności tworzenia niestandardowego kodu aplikacji lub bezpośredniego ładowania z zdalnych źródeł danych. Serwery połączone oferują następujące korzyści:
Możliwość uzyskiwania dostępu do danych spoza programu SQL Server.
Możliwość wystawiania rozproszonych zapytań, aktualizacji, poleceń i transakcji w heterogenicznych źródłach danych w całym przedsiębiorstwie.
Możliwość podobnego rozwiązywania problemów z różnymi źródłami danych.
Serwer połączony można skonfigurować przy użyciu programu SQL Server Management Studio lub instrukcji sp_addlinkedserver . Dostawcy OLE DB różnią się znacznie w typie i liczbie wymaganych parametrów. Na przykład niektórzy dostawcy wymagają podania kontekstu zabezpieczeń dla połączenia przy użyciu sp_addlinkedsrvlogin. Niektórzy dostawcy OLE DB umożliwiają programowi SQL Server aktualizowanie danych w źródle OLE DB. Inne zapewniają dostęp tylko do danych tylko do odczytu. Aby uzyskać informacje o każdym dostawcy OLE DB, zapoznaj się z dokumentacją tego dostawcy OLE DB.
Składniki serwera połączonego
Definicja serwera połączonego określa następujące obiekty:
Dostawca OLE DB
Źródło danych OLE DB
Dostawca OLE DB to biblioteka DLL, która zarządza określonym źródłem danych i współdziała z nim. Źródło danych OLE DB identyfikuje określoną bazę danych, do których można uzyskać dostęp za pośrednictwem OLE DB. Mimo że źródła danych, których dotyczy zapytanie za pośrednictwem połączonych definicji serwera, są zwykle bazami danych, dostawcy OLE DB istnieją dla różnych plików i formatów plików. Obejmują one pliki tekstowe, dane arkusza kalkulacyjnego oraz wyniki wyszukiwania zawartości pełnotekstowej.
Począwszy od programu SQL Server 2019 (15.x), sterownik Microsoft OLE DB dla programu SQL Server (PROGID: MSOLEDBSQL) jest domyślnym dostawcą OLE DB. We wcześniejszych wersjach domyślny dostawca OLE DB był klientem natywnym programu SQL Server (PROGID: SQLNCLI11).
Ważne
SQL Server Native Client (często skracany jako SNAC) został usunięty z SQL Server 2022 (16.x) i SQL Server Management Studio 19 (SSMS). Zarówno dostawca OLE DB klienta natywnego programu SQL Server (SQLNCLI lub SQLNCLI11), jak i starszy dostawca MICROSOFT OLE DB dla programu SQL Server (SQLOLEDB) nie są zalecane w przypadku nowego programowania. Przełącz się na nowy sterownik Microsoft OLE DB (MSOLEDBSQL) dla programu SQL Server na przyszłość.
Serwery połączone ze źródłami programu Microsoft Access i Excel są obsługiwane tylko przez firmę Microsoft w przypadku korzystania z 32-bitowego dostawcy Microsoft.JET.OLEDB.4.0 OLE DB.
Uwaga / Notatka
Zapytania rozproszone programu SQL Server są przeznaczone do pracy z dowolnym dostawcą OLE DB, który implementuje wymagane interfejsy OLE DB. Jednak program SQL Server został przetestowany pod kątem domyślnego dostawcy OLE DB.
Szczegóły serwera połączonego
Poniższa ilustracja przedstawia podstawy konfiguracji serwera połączonego.
Zazwyczaj serwery połączone są używane do obsługi zapytań rozproszonych. Gdy aplikacja kliencka wykonuje zapytanie rozproszone za pośrednictwem połączonego serwera, program SQL Server analizuje polecenie i wysyła żądania do bazy danych OLE DB. Żądanie zestawu wierszy może być w formie wykonywania zapytania względem dostawcy lub otwierania tabeli podstawowej od dostawcy.
Aby źródło danych zwracało dane za pośrednictwem serwera połączonego, dostawca OLE DB (DLL) dla tego źródła danych musi znajdować się na tym samym serwerze co wystąpienie programu SQL Server.
Serwery połączone obsługują przekazywane uwierzytelnianie Active Directory w przypadku użycia pełnego delegowania. Począwszy od programu SQL Server 2017 (14.x) CU17, obsługiwane jest również uwierzytelnianie przekazywane z ograniczonym delegowaniem; jednak ograniczone delegowanie oparte na zasobach nie jest obsługiwane.
Ważne
Gdy jest używany dostawca OLE DB, konto, w ramach którego działa usługa SQL Server, musi mieć uprawnienia do odczytu i wykonywania katalogu oraz wszystkich podkatalogów, w których jest zainstalowany dostawca. Obejmuje to dostawców wydanych przez firmę Microsoft i wszystkich dostawców innych firm.
Zarządzanie dostawcami
Istnieje zestaw opcji, które kontrolują sposób ładowania programu SQL Server i używają dostawców OLE DB określonych w rejestrze.
Zarządzanie definicjami serwera połączonego
Podczas konfigurowania serwera połączonego zarejestruj informacje o połączeniu i informacje o źródle danych za pomocą programu SQL Server. Po zarejestrowaniu tego źródła danych można odwoływać się do niego za pomocą jednej nazwy logicznej.
Aby zarządzać definicjami serwera połączonego, można użyć procedur składowanych i widoków wykazu:
Utwórz połączoną definicję serwera, uruchamiając polecenie
sp_addlinkedserver.Wyświetl informacje o serwerach powiązanych zdefiniowanych w instancji SQL Server, uruchamiając zapytanie do widoku katalogu systemowego
sys.servers.Usuń definicję serwera połączonego, uruchamiając polecenie
sp_dropserver. Można również użyć tej procedury składowanej do usunięcia serwera zdalnego.
Serwery połączone można również zdefiniować przy użyciu programu SQL Server Management Studio. W Eksploratorze obiektów kliknij prawym przyciskiem myszy pozycję Obiekty serwera, wybierz pozycję Nowy, a następnie wybierz pozycję Serwer połączony. Możesz usunąć definicję serwera połączonego, klikając prawym przyciskiem myszy nazwę połączonego serwera i wybierając polecenie Usuń.
Podczas wykonywania zapytania rozproszonego na połączonym serwerze dołącz w pełni kwalifikowaną czteroczęściową nazwę tabeli dla każdego źródła danych. Ta czteroczęściowa nazwa powinna mieć postać <linked_server_name>.<catalog>.<schema>.<object_name>.
Odwołania do obiektów tymczasowych zawsze będą rozpoznawane jako lokalne wystąpienia tempdb, w stosownych przypadkach, i nawet gdy poprzedzają nazwę połączonego serwera.
Serwery połączone można zdefiniować tak, aby wskazywały wstecz (w pętli zwrotnej) na serwer, na którym są zdefiniowane. Serwery loopback są najbardziej przydatne podczas testowania aplikacji korzystającej z zapytań rozproszonych w sieci jednego serwera. Serwery połączone poprzez sprzężenie zwrotne są przeznaczone do testowania i nie obsługują wielu operacji, takich jak transakcje rozproszone.
Połączone serwery z usługą Azure SQL Managed Instance
Połączone serwery usługi Azure SQL Managed Instance obsługują zarówno uwierzytelnianie SQL, jak i uwierzytelnianie za pomocą identyfikatora Entra firmy Microsoft (dawniej Azure Active Directory).
Aby użyć zadań agenta SQL w usłudze Azure SQL Managed Instance do wykonywania zapytań do serwera zdalnego za pośrednictwem serwera połączonego, użyj sp_addlinkedsrvlogin, aby utworzyć mapowanie z loginu na serwerze lokalnym do loginu na serwerze zdalnym. Gdy zadanie agenta SQL łączy się z serwerem zdalnym za pośrednictwem połączonego serwera, wykonuje zapytanie T-SQL w kontekście zdalnego logowania. Aby uzyskać więcej informacji, zobacz Zadania agenta SQL w usłudze Azure SQL Managed Instance.
Uwierzytelnianie usługi Microsoft Entra
Dwa obsługiwane tryby uwierzytelniania Microsoft Entra to: tożsamość zarządzana oraz uwierzytelnianie z przekazem. Można użyć uwierzytelniania tożsamości zarządzanej, aby umożliwić lokalne logowanie i odpytywanie zdalnych połączonych serwerów. Uwierzytelnianie przekazywane pozwala jednostce, która potrafi uwierzytelnić się przy użyciu lokalnego wystąpienia, uzyskać dostęp do zdalnego wystąpienia za pośrednictwem połączonego serwera.
Aby użyć uwierzytelniania Microsoft Entra Pass-Through dla serwera połączonego w usłudze Azure SQL Managed Instance, potrzebne są następujące warunki wstępne:
- Ten sam użytkownik jest dodawany jako login na serwerze zdalnym.
- Obie instancje są członkami grupy zaufania SQL.
Uwaga / Notatka
Istniejące definicje połączonych serwerów, skonfigurowane dla trybu przekazywania, obsługują uwierzytelnianie Microsoft Entra. Jedynym wymaganiem jest dodanie usługi SQL Managed Instance do grupy zaufania serwera.
Następujące ograniczenia dotyczą uwierzytelniania usługi Microsoft Entra dla serwerów połączonych w usłudze Azure SQL Managed Instance:
- Uwierzytelnianie Microsoft Entra nie jest obsługiwane dla zarządzanych wystąpień SQL w różnych dzierżawach Microsoft Entra.
- Uwierzytelnianie Microsoft Entra dla serwerów połączonych jest obsługiwane tylko w przypadku sterownika OLE DB w wersji 18.2.1 lub nowszej.
SQL Server 2025 i MSOLEDBSQL w wersji 19
Począwszy od programu SQL Server 2025 (17.x), dostawca MSOLEDBSQL domyślnie używa sterownika MICROSOFT OLE DB 19. Ten zaktualizowany sterownik wprowadza znaczące ulepszenia zabezpieczeń, w tym obsługę TDS 8.0 i TLS 1.3.
TDS 8.0 zwiększa bezpieczeństwo, dodając nową opcję szyfrowania i wprowadzając zmianę powodującą niezgodność: Encryption parametr nie jest już opcjonalny. Należy go ustawić w parametrach połączenia podczas określania wartości docelowej dla innego wystąpienia programu SQL Server.
Uwaga / Notatka
Bez parametru Encrypt, serwery połączone w programie SQL Server 2025 (17.x) domyślnie ustawiane są na Encrypt=Mandatory oraz wymagają prawidłowego certyfikatu. Połączenia bez prawidłowego certyfikatu kończą się niepowodzeniem.
Parametr Encryption oferuje trzy odrębne ustawienia:
-
Yes, lub , lubTrueMandatory -
No, lub , lubFalseOptional Strict
Opcja Strict nakazuje użycie TDS 8.0 i wymaga certyfikatu serwera na potrzeby bezpiecznych połączeń. W przypadku Yes/True/Mandatory oczekiwano zaufanego certyfikatu. Nie można użyć certyfikatu z podpisem własnym.
| Wersja OLE DB | Parametr szyfrowania | Możliwe wartości | Wartość domyślna |
|---|---|---|---|
| OLE DB 18 | Fakultatywny |
Truelub , Mandatory lub FalseNo |
No |
| OLE DB 19 | Wymagane |
Nolub False, Yes (MandatoryStrictnowy) |
Yes |
Parametr TrustServerCertificate jest obsługiwany, ale nie jest zalecany. Ustawienie certyfikatu serwera zaufania w celu Yes wyłączenia weryfikacji certyfikatu, osłabiając zabezpieczenia szyfrowanych połączeń. Aby można było używać certyfikatu serwera zaufania , klient musi również włączyć go w rejestrze maszyn. Aby uzyskać informacje na temat włączania certyfikatu serwera zaufania, zobacz Ustawienia rejestru. Ustawienie TrustServerCertificate=Yes nie jest zalecane w przypadku środowisk produkcyjnych.
W przypadku używania polecenia Encrypt=False lub Encrypt=Optional:
- Certyfikat nie jest wymagany.
- Jeśli zostanie podany zaufany certyfikat, nie zostanie zweryfikowany.
- Nie zapewnia żadnego szyfrowania połączeń.
W przypadku korzystania z polecenia lub Encrypt=True nie przy użyciu polecenia :Encrypt=MandatoryTrustServerCertificate=Yes
- Wymaga prawidłowego certyfikatu podpisanego przez urząd certyfikacji.
- Certyfikat musi być zgodny z nazwą FQDN serwera.
- Jeśli alternatywna nazwa certyfikatu różni się od nazwy hosta programu SQL Server,
HostNameInCertificatenależy ustawić nazwę FQDN. - Certyfikat należy zainstalować w magazynie zaufanych głównych urzędów certyfikacji na komputerze klienckim.
W przypadku korzystania z polecenia Encrypt=Strict:
- Wymusza TDS 8.0.
- Wymaga prawidłowego certyfikatu podpisanego przez urząd certyfikacji z dopasowaną nazwą FQDN.
-
HostNameInCertificatemusi być ustawiona na nazwę FQDN. - Certyfikat musi być zaufany przez system kliencki.
-
TrustServerCertificatekonfiguracja nie jest obsługiwana. Oznacza to, że musi istnieć prawidłowy certyfikat.
| Ustawienie klienta certyfikatu serwera zaufania | Parametry połączenia/atrybut połączenia Certyfikat serwera zaufania | Walidacja certyfikatu |
|---|---|---|
| 0 |
No (ustawienie domyślne) |
Tak |
| 0 | Yes |
Tak |
| 1 |
No (ustawienie domyślne) |
Tak |
| 1 | Yes |
Nie. |
Te ustawienia muszą być poprawnie określone w parametrach połączenia podczas konfigurowania połączeń serwera połączonego, aby zapewnić zgodność i bezpieczeństwo nowego sterownika.
Aktualizowanie z poprzednich wersji OLEDB
Dotyczy: SQL Server 2025 (17.x) i nowsze wersje
Podczas migracji z poprzednich edycji programu SQL Server do programu SQL Server 2025 (17.x) ze sterownikiem Microsoft OLE DB Driver 19 istniejące połączone konfiguracje serwera mogą zakończyć się niepowodzeniem. Różne wartości domyślne parametru szyfrowania mogą spowodować ten błąd, chyba że podano prawidłowy certyfikat.
Alternatywnie można ponownie utworzyć połączony serwer i dołączyć Encrypt=Optional go do parametrów połączenia. Jeśli nie możesz zmodyfikować konfiguracji serwera połączonego, włącz flagę 17600 śledzenia, aby zachować zachowanie i ustawienia domyślne OLE DB 18.
W Kreatorze tworzenia serwera połączonego programu SQL Server Managed Studio (SSMS) opcja Inne źródła danych musi służyć do ręcznego konfigurowania opcji szyfrowania serwera połączonego.
Aby uzyskać więcej informacji na temat OLE DB 19 oraz szyfrowania, certyfikatów i zachowania certyfikatu serwera zaufanego dla OLE DB 19, zobacz Szyfrowanie i walidacja certyfikatów w OLE DB.