リンクサーバーでMicrosoft ODBC Driver 13 for SQL Serverの使用を保証するにはどうすればよいですか？

Question

SQL Server 2016では、リンクサーバーでMicrosoft ODBC Driver 13 for SQL Serverを使用することをどのように保証しますか？MSDASQLプロバイダーなど、そこに別のレイヤーが存在してもかまいませんが、 SQL ServerのODBC Driver 13を、最終的に削除インスタンスへの接続を作成するものにする必要があります。

Windows 2016 Technical Preview 4のSQL Server 2016 RC2でテストすると、両方とも空のVMに新規インストールされます。odbcad32を使用して、MSODBCSQL13.DLLというファイル名の「ODBC Driver 13 for SQL Server」バージョン2015.130.1300.275を確認できます。

64ビットのodbcad32画面とc：\ windows\syswow64の32ビットのodbcad32画面では、バージョンとファイル名が同じであるため、現時点では32ビットと64ビットの問題であるとは思わない（特にドライバはSQL Server 2016 RC2インストールによってインストールされたため）。

たとえばSQL 2014では、Native Client 11を使用するには、

EXEC master.dbo.sp_addlinkedserver @server = N'LinkName', @srvproduct=N'sql_server', @provider=N'SQLNCLI11', @datasrc=N'YourTargetServer'

SQL 2016 RC2で、試してみると

EXEC master.dbo.sp_addlinkedserver @server = N'LinkName', @srvproduct=N'sql_server', @provider=N'MSODBCSQL13', @datasrc=N'YourTargetServer'

リンクサーバーは問題なく作成されますが、使用しようとすると次のようになります。

Msg 7403, Level 16, State 1, Line 7 The OLE DB provider "MSODBCSQL13" has not been registered.

プロバイダー名ODBC SQL Serverのドライバー13 Microsoft ODBC SQL Serverのドライバー13

または、MSDASQLプロバイダーが名前を付けた組み合わせを試すこともできます。

Windowsで常に暗号化を使用ODBC Driver および sp_addlinkedserver（Transact-SQL）

また、レジストリを調べても、認識したプロバイダー名は明らかになりませんでした。

実際には、ODBCAD32を使用してシステムDSNを作成すると、SQL ServerのODBC Driver 13を選択すると正常にテストされるため、動作することがわかります。

理想的には、新しいODBCドライバをその中に指定するサンプルのsp_addlinkedserverコマンドが欲しいだけです。

texasrebelaggie · Accepted Answer

リンクサーバーがOLEDBインターフェイスに依存していることは事実ですが、ODBCドライバーはSQL Serverサーバー間で安全に使用できます（そのような構成はMicrosoftでサポートされていないという誤解があります。それは神話です。）

リンクサーバーを使用してODBC Driver 11、13、または13.1を使用します。

EXEC master.dbo.sp_addlinkedserver @server = N'LinkedServerName', @srvproduct=N'', @provider=N'MSDASQL', @provstr=N'DRIVER={ODBC Driver 13 for SQL Server};MultiSubnetFailover=Yes;ApplicationIntent=READONLY;Trusted_Connection=Yes;SERVER=FqnServerName;'

ODBC 13.1ドライバーはアップデートであり、「ODBC Driver 13. for SQL Server」ではなく、「ODBC Driver 13 for SQL Server」というドライバー名を使用しています。

私のテストでは、特にAGに接続するときに、完全修飾サーバー名を使用する方が信頼性が高いように見えますが、いつでもサーバー名だけを試すことができます。

サーバー間のKerberos接続をテストできますが、OPENROWSETを使用します。 Kerberosをテストする1つの方法は、ソースサーバーから実行される単純なクエリを使用することです。

SELECT * FROM OPENROWSET(N'MSDASQL', N'Driver={ODBC Driver 13 for SQL Server};Server=FqnServerName;Database=master;Trusted_Connection=yes;MultiSubNetFailover=yes;', N'SELECT * FROM [sys].[databases]') AS [Source]

このエラーが表示された場合は、サーバー間でKerberosを構成する必要があります。

リンクサーバー "（null）"のOLE DBプロバイダー "MSDASQL"がメッセージ "[Microsoft] [ODBC Driver 13 for SQL Server] [SQL Server] Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'。"を返しました。

2012 Native Clientは現在（5年以上）経過しており、Microsoftによって正式に非推奨になっています。Microsoftのロードマップに合わせる場合は、ODBCを使用する必要があります。 2014年に、2012 Native Clientがまだ2歳であったことを考慮してください。ここで、SQL Server 2016およびSQL Server 2017に追加された、2012 Native Clientでサポートされていないすべての機能を検討してください。ODBC Driver 13.1 for SQL Serverを使用することには大きなユースケースがあります。

昨年の中頃から、私の組織はSQL Server 2016に移行しており、SQL Server 2017（CTP 2.1）をテストしています。私はすべてのリンクサーバー（少なくともSQL Server 2016またはSQL Server 2017を指すサーバー）を移行してODBC Driver 13（より正確には13.1））を使用し、まだ確認していませんSQL Server 2016に対する1年以上のテストでの深刻な問題。

（完全な開示のために、リンクサーバーを使用するグラフテーブルに問題があります。ODBC 13.1を使用するリンクサーバーに基づいて問題をMicrosoftに報告しましたが、Microsoftはグラフテーブルを確認していませんSQL Server 2017の（あらゆる種類の）リンクサーバーでサポートされます。

問題が発生した場合はお知らせください。お手伝いします。

SQLmojoe · Answer

ODBCだけを使用することはできません。リンクサーバーは、OLEDBインターフェイスに依存する分散クエリを使用します。これは、オプションまたは交換可能なAPIではありません。そのAPIの下には、任意のOLEDB、ODBC、またはその実装がOLEDBインターフェースをサポートしている限り、JDBCプロバイダーさえも含まれます。たとえば、ODBC =これは、SQL Server以外のデータソースに対してDQを実行する最も一般的な方法の1つです。SQLServerはOLEDBをネイティブでサポートしているため、追加のレイヤーは必要ありません。この情報のほとんどまたはすべては、Books OnlineまたはMSDNにあります。

ODBCのみを使用する必要があるのはなぜですか？ Always Encryptedの場合は、機能リクエストを https://connect.Microsoft.com/SQLServer/feedback/ でログに記録することをお勧めします。 DQを介してAEを実行するシナリオがサポートされているかどうかはわかりません。「呼び出しSQLサーバー」は基本的に「ターゲットSQLサーバー」のクライアントになりますが、DQは変更できるものではないため、クライアントを完全に制御することはできません。

それが他の理由である場合は、ここで詳細を共有してください。そうすれば、他の解決策を考え出すのに役立ちます。