SQL ServerのLinked ServerでMsg 7356が発生する原因と確認方法
公開日 2026-08-13 · 更新日 2026-08-13 · 最終検証日 2026-08-13
結論
Msg 7356 は「リンクサーバーの OLE DB プロバイダーが列に対して一貫性のないメタデータを返した」というエラーです。分散クエリではコンパイル時と実行時の2回、列の型・長さ・NULL 許容をプロバイダーに確認しており、この応答が食い違うと発生します。リモート側のビュー定義変更、テキスト系や計算列、行ごとにメタデータを返す異種プロバイダーが典型です。回避には `OPENQUERY` などのパススルークエリが有効です。
この文書の適用条件
| 対象製品 | SQL Server(リンクサーバー経由の分散クエリ) |
|---|---|
| 確認バージョン | SQL Server 2008 以降(メッセージ番号 7356 は広く共通。プロバイダー固有の挙動は要確認) |
| 適用環境 | オンプレミス、EC2、Amazon RDS(RDS ではリンクサーバーの利用可否に制約があるため要確認) |
| 必要権限 | 設定確認は VIEW ANY DEFINITION または sysadmin。リンクサーバー・プロバイダーオプションの変更は ALTER ANY LINKED SERVER または sysadmin |
| 実行影響 | 確認系は参照のみ。プロバイダーオプションの変更はインスタンス上の全リンクサーバーに影響します |
| 再起動 | プロバイダーオプションによっては SQL Server サービスの再起動が必要になる場合があります(要確認) |
| 最終検証日 | 2026-08-13 |
そのまま実行できるコマンド
- 対象
- SQL Server 2008 以降
- 権限
- VIEW ANY DEFINITION または sysadmin
- 変更作業
- なし(参照のみ)
- Production実行
- 可能
-- 対象: SQL Server 2008 以降
-- 権限: VIEW ANY DEFINITION または sysadmin
-- 変更作業: なし(参照のみ)
-- Production 実行: 可能
SELECT
s.server_id,
s.name,
s.product,
s.provider,
s.data_source,
s.catalog,
s.is_linked,
s.is_remote_login_enabled,
s.is_rpc_out_enabled,
s.is_data_access_enabled,
s.is_collation_compatible,
s.uses_remote_collation,
s.collation_name,
s.lazy_schema_validation,
s.modify_date
FROM sys.servers AS s
WHERE s.is_linked = 1
ORDER BY s.name;
GO
-- 従来型の確認用ストアドプロシージャ
EXEC sp_helpserver;
EXEC sp_linkedservers;`provider` 列で使用中の OLE DB プロバイダー(`SQLNCLI11`、`MSOLEDBSQL`、`MSOLEDBSQL19`、`MSDASQL` など)が分かります。古いプロバイダーを使い続けている場合、メタデータの扱いが現行版と異なることがあります。`is_rpc_out_enabled` は `EXEC ... AT` を使うために必要です。
- 対象
- SQL Server 2008 以降
- 権限
- リンクサーバーのログインマッピングとリモート側の参照権限
- 変更作業
- なし(参照のみ)
- Production実行
- 可能(エラーの再現確認に使う)
-- 対象: SQL Server 2008 以降
-- 権限: リンクサーバーのログインマッピングとリモート側の参照権限
-- 変更作業: なし(参照のみ)
-- Production 実行: 可能(エラー再現の確認用)
-- この形式ではローカル側がリモートのメタデータを取得してプランを作るため 7356 が起きやすい
SELECT col1, col2
FROM [LEGACY-SQL01].[SampleDB].[dbo].[SampleTable];4部構成名の分散クエリでは、ローカルの SQL Server がリモート側の列メタデータを取得してから実行プランを作ります。この「コンパイル時に取得したメタデータ」と「実行時にプロバイダーが返したメタデータ」が食い違うと Msg 7356 になります。まずこの形式でエラーが再現するかを確認してください。
- 対象
- SQL Server 2008 以降(`EXEC ... AT` は RPC OUT が有効であること)
- 権限
- リンクサーバーのログインマッピングとリモート側の参照権限
- 変更作業
- なし(参照のみ)
- Production実行
- 可能
-- 対象: SQL Server 2008 以降(EXEC ... AT は RPC OUT が有効であること)
-- 権限: リンクサーバーのログインマッピングとリモート側の参照権限
-- 変更作業: なし(参照のみ)
-- Production 実行: 可能
-- 1) OPENQUERY: リモート側でクエリを実行し、結果セットだけを受け取る
SELECT col1, col2
FROM OPENQUERY([LEGACY-SQL01],
'SELECT col1, col2 FROM SampleDB.dbo.SampleTable WHERE col1 > 0');
-- 2) EXEC ... AT: 完全なパススルー(RPC OUT が必要)
EXEC ('SELECT col1, col2 FROM SampleDB.dbo.SampleTable WHERE col1 > 0')
AT [LEGACY-SQL01];
-- 3) 型が曖昧な列はリモート側で明示的にキャストする
SELECT note_column
FROM OPENQUERY([LEGACY-SQL01],
'SELECT CAST(note_column AS nvarchar(4000)) AS note_column
FROM SampleDB.dbo.SampleTable');パススルーではリモート側がクエリを実行し、ローカルは結果セットを受け取るだけになります。列メタデータの往復が減るため 7356 を回避できることが多い方法です。`EXEC ... AT` を使うにはリンクサーバーの RPC OUT を有効にする必要があります。
- 対象
- SQL Server 2008 以降(リモートサーバー側で実行)
- 権限
- リモート側で対象ビューへの ALTER 権限
- 変更作業
- あり(ビューのメタデータを再生成し、依存プランを再コンパイルさせる)
- Production実行
- 実行可能だが、対象ビューを参照する処理の再コンパイルが発生する
-- 対象: SQL Server 2008 以降(リモートサーバー側で実行する)
-- 権限: リモート側で対象ビューへの ALTER 権限
-- 変更作業: あり(ビューのメタデータ再生成・依存プランの再コンパイル)
-- Production 実行: 可能。ただし再コンパイルが発生するため時間帯を選ぶこと
USE [SampleDB];
GO
-- 基になるテーブルの列変更に追随できていないビューを再整合させる
EXEC sys.sp_refreshview N'dbo.SampleView';
GO
-- 影響を受けそうなビューを洗い出す(参照のみ)
SELECT
SCHEMA_NAME(v.schema_id) AS schema_name,
v.name AS view_name,
v.modify_date
FROM sys.views AS v
WHERE v.is_ms_shipped = 0
ORDER BY v.modify_date DESC;リモート側のビューが、基になるテーブルの列変更(型変更・列追加)に追随していない状態は Msg 7356 の代表的な要因です。`SELECT *` を含むビューは特にずれやすくなります。この対処が有効かどうかは、リモート側で列定義変更の履歴があるかどうかで判断してください。
- 対象
- SQL Server 2008 以降(リモートサーバー側で実行)
- 権限
- リモート側で対象プロシージャへの ALTER 権限
- 変更作業
- あり(ストアドプロシージャの定義変更)
- Production実行
- 変更管理の手順に従って適用すること
-- 対象: SQL Server 2008 以降(リモートサーバー側で実行する)
-- 権限: リモート側で対象プロシージャへの ALTER 権限
-- 変更作業: あり(ストアドプロシージャの定義変更)
-- Production 実行: 変更管理の手順に従うこと
USE [SampleDB];
GO
ALTER PROCEDURE dbo.SampleProcedure
AS
BEGIN
-- 行カウントメッセージが余分な結果として扱われるのを防ぐ
SET NOCOUNT ON;
SELECT col1, col2
FROM dbo.SampleTable
WHERE col1 > 0;
END;リンクサーバー越しにプロシージャを呼ぶ場合、行カウントメッセージが余分な結果セットとして扱われ、結果セットの構造把握を妨げることがあります。`SET NOCOUNT ON` は一般的な推奨事項であり、7356 の直接原因とは限りません。「試して改善するか確認する」対処として扱ってください。
- 対象
- SQL Server 2008 以降
- 権限
- ALTER ANY LINKED SERVER または sysadmin
- 変更作業
- あり(対象リンクサーバー経由のクエリ全体の挙動が変わる)
- Production実行
- 実行可能だが、そのリンクサーバーを使う全処理に影響する
-- 対象: SQL Server 2008 以降
-- 権限: ALTER ANY LINKED SERVER または sysadmin
-- 変更作業: あり(対象リンクサーバー経由の全クエリに影響)
-- Production 実行: 可能。ただし影響範囲は当該リンクサーバー全体
-- EXEC ... AT を使うために必要
EXEC sp_serveroption @server = N'LEGACY-SQL01', @optname = N'rpc out', @optvalue = N'true';
-- スキーマ検証の遅延(コンパイル時のスキーマ確認を省く)
-- 効果は環境依存。検証環境で挙動を確認してから適用すること
EXEC sp_serveroption @server = N'LEGACY-SQL01', @optname = N'lazy schema validation', @optvalue = N'true';
-- 変更結果の確認
SELECT name, is_rpc_out_enabled, lazy_schema_validation
FROM sys.servers
WHERE name = N'LEGACY-SQL01';`lazy schema validation` はコンパイル時のスキーマ検証を省略するオプションです。スキーマ変更に起因するエラー全般に対して検討される設定ですが、Msg 7356 に効くかどうかは原因によって異なります。検証環境で効果を確認してから適用する仮説的な対処として扱ってください。
- 対象
- SQL Server 2008 以降
- 権限
- sysadmin
- 変更作業
- あり(同じプロバイダーを使う全リンクサーバーに影響)
- Production実行
- 原則不可。検証環境での確認と、影響範囲の合意を前提とする
-- 対象: SQL Server 2008 以降
-- 権限: sysadmin
-- 変更作業: あり(同じプロバイダーを使うインスタンス上の全リンクサーバーに影響)
-- Production 実行: 原則不可。検証環境で確認し、影響範囲の合意を得てから実施すること
-- プロバイダー名は sys.servers の provider 列で確認した値を使う
EXEC master.dbo.sp_MSset_oledb_prop N'MSOLEDBSQL', N'AllowInProcess', 1;
EXEC master.dbo.sp_MSset_oledb_prop N'MSOLEDBSQL', N'DynamicParameters', 1;プロバイダーオプションはインスタンス上で同じプロバイダーを使うすべてのリンクサーバーに影響します。設定によっては SQL Server サービスの再起動が必要になる場合があるため、適用前に対象環境での挙動を確認してください。変更前の値を控えて、切り戻せる状態にしてから実施します。
結果の読み方
| 列 | 意味 | 確認するポイント |
|---|---|---|
| provider | 使用中の OLE DB プロバイダー名 | 古いプロバイダー(SQLNCLI 系)を使い続けていないか |
| product | リンク先製品名 | SQL Server 以外の異種データソースかどうか。異種プロバイダーはメタデータの返し方が異なる |
| data_source | 接続先 | 意図したサーバー/インスタンスを指しているか |
| is_rpc_out_enabled | RPC OUT が有効か | `EXEC ... AT` を使うには 1 である必要がある |
| is_data_access_enabled | 分散クエリが許可されているか | 0 の場合は4部構成名でのアクセス自体ができない |
| lazy_schema_validation | スキーマ検証を遅延させるか | 設定の有無が挙動に影響することがある。変更する場合は検証環境で確認する |
| is_collation_compatible / uses_remote_collation | 照合順序の扱い | 文字列型の比較・変換で問題が出ている場合の確認対象 |
| modify_date | リンクサーバー定義の最終更新日時 | エラー発生時期と設定変更時期が一致していないか |
こういう状況で使います
- リンクサーバー経由のクエリで Msg 7356「一貫性のないメタデータが提供されました」が発生する
- 同じクエリが成功することも失敗することもあり、再現条件が安定しない
- 4部構成名では失敗するが、`OPENQUERY` に書き換えると成功する
- リモート側のビューやテーブルを変更した直後からエラーが出るようになった
- 特定の列(テキスト系、計算列、集計結果の列)を含めたときだけ失敗する
考えられる原因(可能性の高い順)
01
コンパイル時と実行時でプロバイダーが返すメタデータが異なる
これが Msg 7356 の本質です。SQL Server は分散クエリのコンパイル時に列の型・長さ・NULL 許容をプロバイダーへ問い合わせ、実行時にも同じ情報を確認します。両者が一致しないとこのエラーになります。以下はその具体的なパターンです。
02
リモート側のビュー定義がベーステーブルの変更に追随していない
`SELECT *` を含むビューは、ベーステーブルの列変更後もメタデータが古いまま残ることがあります。`sp_refreshview` で再整合させると解消する場合があります。
03
テキスト系・計算列・式の結果を含んでいる
`text` / `ntext` / `image` といった旧型のラージオブジェクト列や、計算列、リモート側の式で生成された列は、長さや型が確定的に返らないことがあります。リモート側で明示的にキャストすると安定します。
04
異種プロバイダーが行ごとにメタデータを返す
SQL Server 以外のデータソース(ODBC 経由の `MSDASQL` を含む)では、行ごとに異なるメタデータを返す実装が存在します。この場合は分散クエリではなくパススルーで扱うのが基本方針になります。
05
リモートプロシージャが複数の結果セットや行カウントを返す
ストアドプロシージャを呼ぶ場合、行カウントメッセージや条件分岐による結果セットの違いが構造把握を妨げることがあります。`SET NOCOUNT ON` と、結果セットを1つに固定する設計が有効な場合があります(対象環境での確認が必要な仮説です)。
06
プロバイダーのバージョンが古い、または混在している
古い SQL Server Native Client を使い続けている環境では、現行のプロバイダーと挙動が異なる場合があります。プロバイダーの更新で解消することがありますが、更新自体が他の接続にも影響するため検証が必要です。
確認手順
- 1
リンクサーバーの構成とプロバイダーを確認する
参照のみ`sys.servers` で `provider`、`product`、`is_rpc_out_enabled` などを確認します。参照専用です。
- 2
4部構成名で再現するかを確認する
参照のみエラーが出るクエリを最小化し、どの列を含めたときに発生するかを特定します。
- 3
`OPENQUERY` に書き換えて挙動を比較する
参照のみパススルーで成功するなら、原因はローカル側のメタデータ取得段階にあると判断できます。
- 4
問題の列を1つずつ外して切り分ける
参照のみ特定の列を除くと成功する場合、その列の型・定義(計算列、テキスト系、ビュー経由)が原因です。
- 5
リモート側のオブジェクト変更履歴を確認する
参照のみ`sys.views` / `sys.objects` の `modify_date` を確認し、エラー発生時期と一致するかを見ます。
- 6
リモート側で単体実行して成否を確認する
参照のみリモートサーバーに直接接続して同じクエリを実行し、リモート単体では正常であることを確認します。
対応方法
すぐに実施できる低リスクの対応
`OPENQUERY` / `EXEC ... AT` に書き換える
参照のみリモート側でクエリを実行し結果だけを受け取る形にすると、列メタデータの往復が減ります。設定変更を伴わず、影響範囲も限定されるため最初に試す対処です。
問題の列をリモート側で明示的にキャストする
参照のみ`CAST(col AS nvarchar(n))` のように型と長さを固定すると、返されるメタデータが安定します。
`SELECT *` を列指定に変える
参照のみ必要な列だけを指定することで、問題のある列を回避できる場合があります。
事前検討が必要な変更
リモート側のビューを再整合させる
中`sp_refreshview` でビューのメタデータを再生成します。ベーステーブルの列変更に追随できていないケースで有効です。
リモートプロシージャに `SET NOCOUNT ON` を追加する
中結果セットの構造を安定させるための一般的な対処です。効果は環境によるため、適用後に再現するかを確認してください。
旧型のラージオブジェクト列を現行型に移行する
高`text` / `ntext` / `image` を `varchar(max)` / `nvarchar(max)` / `varbinary(max)` に移行します。スキーマ変更のため、アプリケーション側の影響評価が必要です。
プロバイダーを現行版に更新する
高古い SQL Server Native Client から現行の OLE DB ドライバーへ移行します。他の接続にも影響するため、検証環境での確認と段階的な適用が前提です。
再起動・サービス影響を伴う変更
リンクサーバーオプションを変更する
中`lazy schema validation` などの変更は、そのリンクサーバーを使う全処理の挙動に影響します。効果が環境依存であるため、検証環境での確認を前提とします。
OLE DB プロバイダーオプションを変更する
高インスタンス上で同じプロバイダーを使うすべてのリンクサーバーに影響し、サービス再起動が必要になる場合があります。変更前の値を控え、切り戻し可能にしてから実施してください。
リンクサーバー方式そのものを見直す
専門家レビュー必須恒常的にメタデータ不整合が起きる異種データソースでは、リンクサーバーではなくETL/連携基盤経由に切り替える設計変更が根本対策になります。
!注意事項
- Msg 7356 の原因は複数あり、どれが該当するかは環境によって異なります。本記事の対処のうち `sp_refreshview`、`SET NOCOUNT ON`、`lazy schema validation` は「試して効果を確認する仮説的な対処」であり、必ず効くものではありません。
- `sp_MSset_oledb_prop` によるプロバイダーオプションの変更は、インスタンス上で同じプロバイダーを使うすべてのリンクサーバーに影響します。設定によっては SQL Server サービスの再起動が必要になる場合があります。
- `lazy schema validation` を有効にするとコンパイル時のスキーマ検証が省略されます。スキーマ変更に対する検出が遅れる可能性があるため、副作用を理解したうえで適用してください。
- リンクサーバーの認証設定を変更する際は、リモート側のログインマッピングと権限も併せて確認してください。認証まわりの変更は他の連携処理を止める可能性があります。
- Amazon RDS for SQL Server ではリンクサーバーの利用に制約があります。作成可否と対応プロバイダーは対象環境で確認してください。
バージョン・環境による違い
これで解決しない場合に確認すること
リモート側のオブジェクト定義の変更履歴
`sys.objects` / `sys.views` の `modify_date` を確認し、エラー発生時期との関連を見ます。
クエリを最小構成まで削って再現条件を特定する
列を1つずつ減らし、どの列を含めたときに発生するかを確定させます。
リモート側の照合順序と文字列型
照合順序が異なる環境間では、文字列型の扱いで別のエラーが併発することがあります。
エラーログとリングバッファ
SQL Server エラーログに、同時刻の接続エラーやプロバイダー関連のメッセージが記録されていないかを確認します。
この文書の根拠と限界
製品の公式ドキュメントに基づく説明
SQL Server の分散クエリ、`sys.servers`、`sp_serveroption`、`sp_helpserver`、`sp_linkedservers`、`sp_refreshview`、`OPENQUERY` / `EXEC ... AT` の公開仕様、および Msg 7356 のメッセージ定義に基づきます。個々の原因パターンのうち、`lazy schema validation` や `SET NOCOUNT ON` の効果は環境依存であるため、確定した対処ではなく検証すべき仮説として記載しています。プロバイダー固有の内部挙動は対象環境での確認が必要です。
よくある質問
Msg 7356の原因は何ですか?
分散クエリのコンパイル時にプロバイダーが返した列メタデータと、実行時に返したメタデータが食い違ったことを示すエラーです。リモート側のビュー定義がベーステーブルの変更に追随していない、テキスト系や計算列を含んでいる、異種プロバイダーが行ごとにメタデータを返す、といったケースが典型です。
OPENQUERYに書き換えればいつも解決しますか?
多くのケースで有効ですが、常に解決するとは限りません。パススルーではリモート側がクエリを実行し結果だけを返すため、メタデータの往復が減ります。ただし異種プロバイダーの実装によっては、パススルーでも同種のエラーが出ることがあります。
Productionで実行できますか?
`sys.servers` の確認、`OPENQUERY` への書き換え、明示的なキャストはいずれも参照専用で本番環境で実行できます。`sp_refreshview` はビューを参照する処理の再コンパイルを伴い、`sp_serveroption` と `sp_MSset_oledb_prop` は影響範囲が広いため、検証環境での確認を前提としてください。
どの権限が必要ですか?
設定の確認には VIEW ANY DEFINITION または sysadmin が必要です。リンクサーバーオプションの変更には ALTER ANY LINKED SERVER または sysadmin、プロバイダーオプションの変更には sysadmin が必要です。`sp_refreshview` はリモート側で対象ビューへの ALTER 権限が必要です。
AWS RDSでも使用できますか?
Amazon RDS for SQL Server ではリンクサーバーの利用に制約があります。作成可否、対応プロバイダー、実行できるストアドプロシージャの範囲はサービス仕様に依存するため、対象環境で確認してください。
結果をどう判断しますか?
まず4部構成名で再現し、`OPENQUERY` では成功することを確認できれば、ローカル側のメタデータ取得段階が原因だと判断できます。そのうえで列を1つずつ外して問題の列を特定し、リモート側の定義変更履歴と突き合わせてください。
この文書がカバーする質問
- リンクサーバー経由のクエリでメタデータエラーが出る
- 4部構成名では失敗するがOPENQUERYなら成功する理由を知りたい
- リンクサーバーのプロバイダー設定を確認したい
リスク表示の意味
- 参照のみデータと設定を変更しません。
- 低影響は限定的ですが、権限と負荷の確認が必要です。
- 中性能・ロック・コストに影響する可能性があります。
- 高障害・データ損失・復旧作業が発生する可能性があります。
- 専門家レビュー必須本番適用前に別途レビューが必須です。
GIIPの対応範囲
リンクサーバー経由のエラーは、原因がローカル側・リモート側・プロバイダーのどこにあるのか切り分けが難しく、しかも再現条件が安定しないことが多い種類の障害です。GIIP では複数システムをまたぐ連携について、どのサーバーのどのオブジェクトがいつ変更されたかを時系列で保持し、エラー発生時期と突き合わせられる状態にしています。プロバイダーオプションのようにインスタンス全体へ影響する変更は自動化の対象外とし、切り分けと影響範囲の提示までを担当しています。
執筆・技術検証
GIIP プロダクション運用チーム
大規模Webサービス、SQL Server、Oracle、AWS、Azureの設計・移行・運用に約30年従事。x12largeクラスのAWS RDS for SQL Server環境12セット、約12万テーブルのOracle環境、約3TBのTiDBからAurora MySQLへの移行を経験。現在も複数のクラウドデータベースと約30のWebサービスを、AIエージェントと人間の専門家が継続的に監視・運用しています。
SQLNCLI10でTLS 1.2接続が失敗する原因とMSOLEDBSQL 19への移行
SQLNCLI10 のTLS 1.2非対応と、MSOLEDBSQL 19 で既定が Encrypt=yes に変わったことによる接続失敗を切り分け、移行時に確認すべき点を整理します。
sql-serverSQL Serverでテーブルごとの統計情報更新日時を確認するSQL
sys.stats と STATS_DATE で、テーブル・統計ごとの最終更新日時と更新後の変更行数を一覧化する参照専用SQLです。
sql-serverSQL Serverで長時間開いたままのトランザクションを確認するSQL
sys.dm_tran_active_transactions 系のDMVで、開始時刻・セッション・最後に実行したSQLまで含めて放置トランザクションを特定する手順です。
database-migration3TB規模のデータベースを移行するときの計画の立て方
3TB級の移行計画は、サイズの実測、切り替え方式の選択、試験実行による所要時間の実測、検証と切り戻しの設計、の順で組み立てます。目安値ではなく実測値で日程を引くための手順です。
関連サービス
リンクサーバー障害の切り分けを依頼する
同じ確認を複数の環境で継続する必要がある場合は、運用体制ごと相談できます。
リンクサーバー障害の切り分けを依頼する