Causes and Checks for Msg 7356 on a Linked Server in SQL Server
公開日 2026-08-13 · 更新日 2026-08-13 · 最終検証日 2026-08-13
結論
Msg 7356 means "the linked server's OLE DB provider returned inconsistent metadata for a column." A distributed query asks the provider for each column's type, length, and nullability twice — once at compile time and again at run time — and this error fires when the two answers disagree. Typical causes include a changed view definition on the remote side, text-type or computed columns, and a heterogeneous provider that returns different metadata per row. Pass-through queries such as `OPENQUERY` are an effective workaround.
この文書の適用条件
| 対象製品 | SQL Server (distributed queries via a linked server) |
|---|---|
| 確認バージョン | SQL Server 2008 and later (message number 7356 is broadly common; provider-specific behavior needs verification) |
| 適用環境 | On-premises, EC2, Amazon RDS (RDS has restrictions on linked server availability — verify) |
| 必要権限 | Checking the configuration requires VIEW ANY DEFINITION or sysadmin. Changing linked server or provider options requires ALTER ANY LINKED SERVER or sysadmin |
| 実行影響 | The check commands are read-only. Changing provider options affects every linked server on the instance |
| 再起動 | Depending on the provider option, a restart of the SQL Server service may be required (verify) |
| 最終検証日 | 2026-08-13 |
そのまま実行できるコマンド
- 対象
- SQL Server 2008 and later
- 権限
- VIEW ANY DEFINITION or sysadmin
- 変更作業
- None (read-only)
- Production実行
- Safe to run
-- 対象: 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;The `provider` column shows which OLE DB provider is in use (`SQLNCLI11`, `MSOLEDBSQL`, `MSOLEDBSQL19`, `MSDASQL`, etc.). If you are still on an old provider, its metadata handling may differ from current versions. `is_rpc_out_enabled` needs to be on to use `EXEC ... AT`.
- 対象
- SQL Server 2008 and later
- 権限
- The linked server's login mapping, and read permission on the remote side
- 変更作業
- None (read-only)
- Production実行
- Safe to run (used to reproduce the error)
-- 対象: SQL Server 2008 以降
-- 権限: リンクサーバーのログインマッピングとリモート側の参照権限
-- 変更作業: なし(参照のみ)
-- Production 実行: 可能(エラー再現の確認用)
-- この形式ではローカル側がリモートのメタデータを取得してプランを作るため 7356 が起きやすい
SELECT col1, col2
FROM [LEGACY-SQL01].[SampleDB].[dbo].[SampleTable];In a four-part-name distributed query, the local SQL Server fetches the remote side's column metadata before building an execution plan. When this "metadata fetched at compile time" disagrees with "the metadata the provider returns at run time," you get Msg 7356. First confirm whether the error reproduces in this form.
- 対象
- SQL Server 2008 and later (`EXEC ... AT` requires RPC OUT to be enabled)
- 権限
- The linked server's login mapping, and read permission on the remote side
- 変更作業
- None (read-only)
- Production実行
- Safe to run
-- 対象: 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');With a pass-through query, the remote side executes the query and the local side simply receives the result set. This reduces the back-and-forth of column metadata, and often avoids 7356. Using `EXEC ... AT` requires enabling RPC OUT on the linked server.
- 対象
- SQL Server 2008 and later (run on the remote server)
- 権限
- ALTER permission on the target view, on the remote side
- 変更作業
- Yes (regenerates the view metadata and forces dependent plans to recompile)
- Production実行
- Can be run, but causes a recompile of anything that references the view
-- 対象: 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;A remote-side view that has not kept up with a column change (a type change, a new column) on its base table is a classic cause of Msg 7356. Views containing `SELECT *` are especially prone to drifting out of sync. Judge whether this fix applies based on whether there is a history of column changes on the remote side.
- 対象
- SQL Server 2008 and later (run on the remote server)
- 権限
- ALTER permission on the target procedure, on the remote side
- 変更作業
- Yes (changes the definition of the stored procedure)
- Production実行
- Apply according to your change management process
-- 対象: 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;When calling a procedure across a linked server, row-count messages can be treated as an extra result set, interfering with determining the result set's structure. `SET NOCOUNT ON` is a general-purpose recommendation, and may not be the direct cause of 7356 — treat it as a fix to try and check for improvement.
- 対象
- SQL Server 2008 and later
- 権限
- ALTER ANY LINKED SERVER or sysadmin
- 変更作業
- Yes (changes the behavior of all queries through the target linked server)
- Production実行
- Can be run, but affects every process using that linked server
-- 対象: 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` skips schema validation at compile time. It is a setting worth considering for schema-change-related errors in general, but whether it helps with Msg 7356 specifically depends on the cause. Treat it as a hypothesis to verify in a test environment before applying.
- 対象
- SQL Server 2008 and later
- 権限
- sysadmin
- 変更作業
- Yes (affects every linked server using the same provider)
- Production実行
- Not allowed as a rule. Requires verification in a test environment and agreement on the scope of impact
-- 対象: 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;Provider options affect every linked server on the instance that uses the same provider. Depending on the setting, a restart of the SQL Server service may be required, so check the behavior on the target environment before applying. Record the prior values so you can roll back before doing this.
結果の読み方
| 列 | 意味 | 確認するポイント |
|---|---|---|
| provider | Name of the OLE DB provider in use | Whether you are still on an old provider (the SQLNCLI family) |
| product | Name of the linked product | Whether it is a heterogeneous data source other than SQL Server — such providers return metadata differently |
| data_source | Connection target | Whether it points to the intended server/instance |
| is_rpc_out_enabled | Whether RPC OUT is enabled | Must be 1 to use `EXEC ... AT` |
| is_data_access_enabled | Whether distributed queries are allowed | If 0, four-part-name access itself is not possible |
| lazy_schema_validation | Whether schema validation is deferred | This setting can affect behavior — if changing it, verify in a test environment |
| is_collation_compatible / uses_remote_collation | Handling of collation | A check point if you are seeing problems with string comparison or conversion |
| modify_date | Last modification time of the linked server definition | Whether this coincides with when the error started occurring |
こういう状況で使います
- A query through a linked server fails with Msg 7356, "inconsistent metadata was provided"
- The same query sometimes succeeds and sometimes fails, with no stable reproduction condition
- A four-part name fails, but rewriting it as `OPENQUERY` succeeds
- Errors started appearing right after a view or table was changed on the remote side
- It only fails when a specific column (text-type, computed, or an aggregation result) is included
考えられる原因(可能性の高い順)
01
The provider returns different metadata at compile time versus run time
This is the essence of Msg 7356. SQL Server asks the provider for a column's type, length, and nullability when compiling a distributed query, and checks the same information again at run time. This error occurs when the two disagree. The items below are specific patterns that cause this.
02
The remote-side view definition has not kept up with a change to the base table
A view containing `SELECT *` can retain stale metadata even after a column change on its base table. Reconciling it with `sp_refreshview` can resolve this.
03
The query includes text-type, computed, or expression-derived columns
Legacy large-object columns like `text` / `ntext` / `image`, computed columns, or columns produced by an expression on the remote side can fail to return a deterministic length or type. Casting them explicitly on the remote side stabilizes this.
04
A heterogeneous provider returns different metadata per row
Some implementations of non-SQL-Server data sources (including `MSDASQL` over ODBC) return different metadata row by row. In this case, the basic policy is to handle it via pass-through rather than a distributed query.
05
A remote procedure returns multiple result sets or row counts
When calling a stored procedure, row-count messages or a conditional branch producing a different result set can interfere with determining its structure. `SET NOCOUNT ON` combined with a design that always returns a single result set can help (this is a hypothesis that needs verifying on the target environment).
06
The provider version is outdated or inconsistent across connections
Environments still using an old SQL Server Native Client can behave differently from current providers. Updating the provider can resolve this, but the update itself affects other connections, so it needs verification.
確認手順
- 1
Check the linked server's configuration and provider
参照のみCheck `provider`, `product`, `is_rpc_out_enabled`, and so on in `sys.servers`. Read-only.
- 2
Check whether it reproduces with a four-part name
参照のみMinimize the failing query to identify which column triggers the error.
- 3
Rewrite as `OPENQUERY` and compare behavior
参照のみIf the pass-through version succeeds, you can conclude the cause lies in the local-side metadata-fetch step.
- 4
Remove the suspect columns one at a time to isolate the cause
参照のみIf excluding a specific column makes it succeed, that column's type or definition (computed, text-type, or via a view) is the cause.
- 5
Check the change history of remote-side objects
参照のみCheck `modify_date` in `sys.views` / `sys.objects` to see whether it lines up with when the error started.
- 6
Run it standalone on the remote side to confirm success
参照のみConnect directly to the remote server and run the same query to confirm it succeeds on its own.
対応方法
すぐに実施できる低リスクの対応
Rewrite as `OPENQUERY` / `EXEC ... AT`
参照のみHaving the remote side execute the query and returning only the result reduces the round-tripping of column metadata. This requires no configuration change and has a limited scope, making it the first thing to try.
Explicitly cast the problem column on the remote side
参照のみFixing the type and length, e.g. `CAST(col AS nvarchar(n))`, stabilizes the metadata returned.
Replace `SELECT *` with explicit column names
参照のみSpecifying only the columns you need can sidestep a problematic column.
事前検討が必要な変更
Reconcile the remote-side view
中Use `sp_refreshview` to regenerate the view's metadata. Effective when the view has not kept up with a column change on its base table.
Add `SET NOCOUNT ON` to the remote procedure
中A general-purpose fix for stabilizing the structure of the result set. Its effect depends on the environment, so verify whether the issue still reproduces after applying it.
Migrate legacy large-object columns to current types
高Migrate `text` / `ntext` / `image` to `varchar(max)` / `nvarchar(max)` / `varbinary(max)`. This is a schema change, so it requires an application-side impact assessment.
Update the provider to a current version
高Migrate from the old SQL Server Native Client to a current OLE DB driver. This affects other connections too, so it requires verification in a test environment and a staged rollout.
再起動・サービス影響を伴う変更
Change a linked server option
中A change such as `lazy schema validation` affects the behavior of everything using that linked server. Its effect depends on the environment, so this assumes verification in a test environment.
Change an OLE DB provider option
高This affects every linked server on the instance using the same provider, and may require a service restart. Record the prior values so you can roll back before doing this.
Reconsider the linked-server approach itself
専門家レビュー必須For a heterogeneous data source where metadata inconsistency happens persistently, switching to an ETL or integration platform instead of a linked server is the root-cause fix. This is a design change.
!注意事項
- Msg 7356 has multiple possible causes, and which one applies depends on the environment. Among the fixes in this article, `sp_refreshview`, `SET NOCOUNT ON`, and `lazy schema validation` are "hypotheses to try and verify" — they are not guaranteed to help.
- Changing a provider option via `sp_MSset_oledb_prop` affects every linked server on the instance using the same provider. Depending on the setting, it may require restarting the SQL Server service.
- Enabling `lazy schema validation` skips schema validation at compile time. Because detection of schema changes can be delayed as a result, apply it only after understanding this side effect.
- When changing a linked server's authentication settings, also check the remote-side login mapping and permissions. Authentication-related changes can break other integrations.
- Amazon RDS for SQL Server has restrictions on using linked servers. Check the target environment for whether creation is allowed and which providers are supported.
バージョン・環境による違い
これで解決しない場合に確認すること
Change history of remote-side object definitions
Check `modify_date` in `sys.objects` / `sys.views` for a correlation with when the error started.
Trim the query down to a minimal repro to pinpoint the condition
Remove columns one at a time to determine which one triggers the error.
Collation and string types on the remote side
Between environments with different collations, string-type handling can trigger a separate, co-occurring error.
The error log and ring buffer
Check the SQL Server error log for connection errors or provider-related messages logged at the same time.
この文書の根拠と限界
製品の公式ドキュメントに基づく説明
Based on the public specifications of SQL Server's distributed queries, `sys.servers`, `sp_serveroption`, `sp_helpserver`, `sp_linkedservers`, `sp_refreshview`, `OPENQUERY` / `EXEC ... AT`, and the Msg 7356 message definition. For some individual cause patterns, the effectiveness of `lazy schema validation` and `SET NOCOUNT ON` depends on the environment, so they are presented as hypotheses to verify rather than confirmed fixes. Provider-specific internal behavior requires verification on the target environment.
よくある質問
What causes Msg 7356?
It is an error indicating that the column metadata a provider returned at compile time for a distributed query disagreed with what it returned at run time. Typical cases are a remote-side view definition that has not kept up with a base-table change, the presence of text-type or computed columns, or a heterogeneous provider that returns different metadata per row.
Does rewriting as OPENQUERY always fix it?
It helps in many cases, but not always. A pass-through has the remote side execute the query and return only the result, reducing metadata round-tripping. However, depending on the heterogeneous provider's implementation, the same kind of error can still occur even through a pass-through.
Can this be run in production?
Checking `sys.servers`, rewriting as `OPENQUERY`, and explicit casting are all read-only and can be run in production. `sp_refreshview` causes a recompile of anything referencing the view, and `sp_serveroption` and `sp_MSset_oledb_prop` have a broad scope of impact, so these assume verification in a test environment first.
What permissions are required?
Checking the configuration requires VIEW ANY DEFINITION or sysadmin. Changing a linked server option requires ALTER ANY LINKED SERVER or sysadmin; changing a provider option requires sysadmin. `sp_refreshview` requires ALTER permission on the target view, on the remote side.
Does this work on AWS RDS?
Amazon RDS for SQL Server has restrictions on using linked servers. Whether you can create one, which providers are supported, and which stored procedures you can run all depend on the service specification, so check the target environment.
How should I interpret the results?
First reproduce it with a four-part name, and if you confirm it succeeds via `OPENQUERY`, you can conclude the cause lies in the local-side metadata-fetch step. From there, exclude columns one at a time to pinpoint the problem column, and cross-reference it against the remote side's definition change history.
この文書がカバーする質問
- Getting a metadata error on a query through a linked server
- I want to know why a four-part name fails but OPENQUERY succeeds
- I want to check a linked server's provider settings
リスク表示の意味
- 参照のみデータと設定を変更しません。
- 低影響は限定的ですが、権限と負荷の確認が必要です。
- 中性能・ロック・コストに影響する可能性があります。
- 高障害・データ損失・復旧作業が発生する可能性があります。
- 専門家レビュー必須本番適用前に別途レビューが必須です。
GIIPの対応範囲
An error through a linked server is a difficult kind of failure to isolate — whether the cause is local, remote, or in the provider — and it often reproduces inconsistently on top of that. At GIIP, for integrations spanning multiple systems, we keep a timeline of which object on which server changed and when, so it can be cross-referenced against when an error started. Changes that affect the whole instance, like a provider option, are excluded from automation — we handle isolation and scoping the impact instead.
執筆・技術検証
GIIP プロダクション運用チーム
大規模Webサービス、SQL Server、Oracle、AWS、Azureの設計・移行・運用に約30年従事。x12largeクラスのAWS RDS for SQL Server環境12セット、約12万テーブルのOracle環境、約3TBのTiDBからAurora MySQLへの移行を経験。現在も複数のクラウドデータベースと約30のWebサービスを、AIエージェントと人間の専門家が継続的に監視・運用しています。
Why TLS 1.2 Connections Fail with SQLNCLI10, and Migrating to MSOLEDBSQL 19
This separates connection failures caused by SQLNCLI10's lack of TLS 1.2 support from those caused by MSOLEDBSQL 19's default changing to Encrypt=yes, and organizes what to check during migration.
sql-serverSQL to Check Statistics Last-Updated Time per Table in SQL Server
A read-only SQL script using sys.stats and STATS_DATE that lists the last-updated time and the number of rows modified since the last update, per table and statistic.
sql-serverSQL to Check for Long-Running Open Transactions in SQL Server
A procedure using the sys.dm_tran_active_transactions family of DMVs to identify abandoned transactions, including start time, session, and the last SQL statement executed.
database-migrationHow to Plan a 3TB-Scale Database Migration
A 3TB-class migration plan is built in this order: measure actual size, choose a cutover method, measure duration with a trial run, and design verification and rollback. This is a procedure for setting the schedule from measured values rather than rule-of-thumb figures.
関連サービス
Request help isolating a linked server failure
同じ確認を複数の環境で継続する必要がある場合は、運用体制ごと相談できます。
Request help isolating a linked server failure