sqldw-operations-cli

テレメトリ — 必須。 すべての api.fabric.microsoft.com 呼び出しに x-ms-fabric-skill: sqldw-operations-cli を付与してください（az rest の場合：--headers "x-ms-fabric-skill=sqldw-operations-cli"）。 fabric_lro や再試行を含め、すべての LRO ポーリングにも必要です。スニペットでは省略されていますが、必ず追加してください。

更新の確認 — セッションにつき 1 回（必須） セッション中にこのスキルを初めて使用するときは、続行する前に check-updates スキルを実行してください。

• GitHub Copilot CLI / VS Code：check-updates スキルを呼び出します。
• Claude Code / Cowork / Cursor / Windsurf / Codex：ローカルとリモートの package.json のバージョンを比較します。
• このセッションの前の時点ですでに確認済みの場合はスキップしてください。

重要な注意事項

1. ワークスペース名から詳細（ID を含む）を確認するには、すべてのワークスペースを一覧表示し、JMESPath フィルタリングを使用します。
2. ワークスペース ID、アイテムの種類、アイテム名からアイテムの詳細（ID を含む）を確認するには、そのワークスペース内の該当する種類のアイテムをすべて一覧表示し、JMESPath フィルタリングを使用します。

SQL DW パフォーマンスと診断 — CLI スキル

このスキルでは、fabric-sqlendpoint-execute_query MCP ツールと組み込みの queryinsights ビューを使用して、Microsoft Fabric Data Warehouse のパフォーマンス分析、詳細な診断、最適化の指針を提供します。すべてのクエリは読み取り専用です。

前提条件

az rest を使ったワークスペース／アイテムの検出については、COMMON-CLI.md § az rest による Fabric コントロールプレーン API を参照してください。従来の sqlcmd のリファレンス（フォールバックのみ）については、COMMON-CLI.md § SQL / TDS データプレーンアクセス を参照してください。

⚠️ SQL 実行の優先設定： SQL データプレーンの実行では、このスキルが COMMON-CLI の SQL/TDS に関するガイダンスに優先します。レガシー CLI フォールバックを明示的に使用する場合を除き、MCP fabric-sqlendpoint-execute_query（ツールスタックを参照）を使用してください。

モニタリング固有の要件：

• ワークスペースのロール：対象ワークスペースの管理者またはメンバー（queryinsights ビューに必要）
• ウェアハウスが存在し、最近のクエリアクティビティがあること（queryinsights ビューには 30 日分が保持されます。データの反映には最大 15 分かかります）

目次

タスク	参照	備考
Fabric のワークスペースとアイテムを見つける	COMMON-CLI.md § Fabric のワークスペースとアイテムを見つける	必須 — 最初にリンクを読むこと [名前からワークスペース ID を、または名前、アイテムの種類、ワークスペース ID からアイテム ID を見つけるために必要です]
Fabric のトポロジと主要な概念	COMMON-CORE.md § Fabric のトポロジと主要な概念
環境 URL	COMMON-CORE.md § 環境 URL
認証とトークンの取得	COMMON-CORE.md § 認証とトークンの取得	audience が間違っていると 401 が返されます。認証の問題が発生した場合は、まずお読みください
コアコントロールプレーン REST API	COMMON-CORE.md § コアコントロールプレーン REST API	ページネーション、LRO のポーリング、レート制限のパターンを含みます
キャパシティ管理	COMMON-CORE.md § キャパシティ管理
注意点、ベストプラクティス、トラブルシューティング（プラットフォーム）	COMMON-CORE.md § 注意点、ベストプラクティス、トラブルシューティング
ツール選択の根拠	COMMON-CLI.md § ツール選択の根拠
認証のレシピ	COMMON-CLI.md § 認証のレシピ	az login のフローとトークンの取得
az rest による Fabric コントロールプレーン API	COMMON-CLI.md § az rest による Fabric コントロールプレーン API	必ず --resource を渡してください。ページネーションと LRO のヘルパーを含みます
SQL / TDS データプレーンへのアクセス	COMMON-CLI.md § SQL / TDS データプレーンへのアクセス	レガシーな sqlcmd の参考情報（MCP が主要な手段です。「ツールスタック」を参照）
注意点とトラブルシューティング（CLI 固有）	COMMON-CLI.md § 注意点とトラブルシューティング（CLI 固有）	az rest の audience、シェルのエスケープ、トークンの有効期限
クイックリファレンス	COMMON-CLI.md § クイックリファレンス	az rest のテンプレートとトークン audience／ツールのマトリックス
接続の基本	SQLDW-CONSUMPTION-CORE.md § 接続の基本	TDS、ポート 1433、Entra のみ、MARS なし
監視と診断	SQLDW-CONSUMPTION-CORE.md § 監視と診断	クエリラベル、DMV（リアルタイム）と queryinsights.*（過去 30 日間の履歴）
パフォーマンス：ベストプラクティスとトラブルシューティング	SQLDW-CONSUMPTION-CORE.md § パフォーマンス：ベストプラクティスとトラブルシューティング	統計、キャッシュ、クラスタリング、クエリのヒント
注意点とトラブルシューティング（コンシュンプション）	SQLDW-CONSUMPTION-CORE.md § 注意点とトラブルシューティングのリファレンス	原因と解決策を含む 18 件の番号付き問題
データ取り込み（DW のみ）	SQLDW-AUTHORING-CORE.md § データ取り込み（DW のみ）	COPY INTO、OPENROWSET、手法の比較
クエリリファレンス	query-reference.md	すべての分析に関する T-SQL クエリ、パラメーター、出力例
複合レシピ	COMMON-CLI.md § 複合レシピ
アイテムの種類別機能マトリックス	SQLDW-CONSUMPTION-CORE.md § アイテムの種類別機能マトリックス	Warehouse のみ — queryinsights は SQLEP では利用できません
前提条件	SKILL.md § 前提条件	ツール、認証、ワークスペースのロール
ツールスタック	SKILL.md § ツールスタック
接続	SKILL.md § 接続
パフォーマンス分析	SKILL.md § パフォーマンス分析	長時間実行クエリ、リソース使用者、ユーザーインサイト、ベースライン
詳細な診断	SKILL.md § 詳細な診断	負荷の高い時間帯、キャッシュの状態、クラスタリングキー
Fabric DW の制約	SKILL.md § Fabric DW の制約	サポートされていない機能を推奨しないでください
ベストプラクティス	SKILL.md § ベストプラクティス	監視に関するガイダンス
エージェント型ワークフロー	SKILL.md § エージェント型ワークフロー	よくある調査パターン
注意点、ルール、トラブルシューティング	SKILL.md § 注意点、ルール、トラブルシューティング	必須／回避／推奨のチェックリスト
例	SKILL.md § 例	プロンプトと応答のペア

---

ツールスタック

インストールとセットアップについては、前提条件を参照してください。

ツール	役割
fabric-sqlendpoint-execute_query MCP ツール	主要：Fabric SQL エンドポイントに対して監視用の T-SQL クエリを実行します。認証は MCP プロトコルによって処理されます。
az CLI	トークンの取得、ワークスペース／アイテム検出のための Fabric REST
jq	az rest の JSON を解析

重要 — MCP と sqlcmd： このスキルでは、すべての T-SQL 実行に fabric-sqlendpoint-execute_query MCP ツールを使用します。クエリの実行に COMMON-CLI の SQL／TDS／sqlcmd セクションを使用しないでください。

エージェントの事前確認 — 初回操作の前に確認してください：

1. ツール一覧で fabric-sqlendpoint-execute_query ツールが利用可能であることを確認します。このツールは fabric-sqlendpoint MCP サーバーによって提供されます。エンドユーザー向けの方法である Fabric スキルのプラグインをインストールするか、このリポジトリの .mcp.json を使用して登録できます。また、他の MCP クライアントでは独自の設定を通じて登録される場合があります。
2. 一致するツールが見つからない場合は、ユーザーが Fabric SQL Endpoint MCP サーバーを登録する必要があります。
   • グローバル URL：https://api.fabric.microsoft.com/v1/mcp/dataPlane/sqlEndpoint
   • アイテムスコープの URL：https://api.fabric.microsoft.com/v1/mcp/dataPlane/workspaces/{workspaceId}/items/{itemId}/sqlEndpoint

MCP ツールのシグネチャ

fabric-sqlendpoint-execute_query(workspaceId, itemId, query)

ツール名は異なる場合があります： execute_query は論理的な操作名です。サーバーの登録方法によっては、ツール一覧に表示される実際のツール名にプレフィックスが付くことがあります（例： fabric-sqlendpoint-execute_query または sqlendpoint-global-execute_query）。ツール一覧に表示されている実際の名前を呼び出し、必ず workspaceId、itemId、および query を渡してください。

パラメーター	型	説明
workspaceId	string (UUID)	対象の Warehouse を含むワークスペースの GUID
itemId	string (UUID)	Warehouse アイテムの GUID
query	string	T-SQL クエリテキスト（単一バッチ — GO 区切り文字は使用不可）

戻り値： 表形式の結果とメタデータテキストを含む CSV リソース（RFC 4180）。

制限： 最大 10,000 行 | タイムアウト 300s | レート制限 20 req/min (観測されたデフォルト値であり、文書化された保証ではありません — サービス側で変更される可能性があります。実際の 429／タイムアウト／切り捨て応答で確認してください)

---

接続

workspaceId と itemId を検出する

fabric-sqlendpoint-execute_query を呼び出すには、ワークスペース GUID とウェアハウス GUID が必要です：

# 1. Find workspace ID by name (capture into WS_ID for the next call)
WS_ID=$(az rest --method get \
  --resource "https://api.fabric.microsoft.com" \
  --url "https://api.fabric.microsoft.com/v1/workspaces" \
  --query "value[?displayName=='MyWorkspace'].id" --output tsv)
echo "Workspace ID: $WS_ID"

# 2. Find warehouse item ID by name
az rest --method get \
  --resource "https://api.fabric.microsoft.com" \
  --url "https://api.fabric.microsoft.com/v1/workspaces/$WS_ID/warehouses" \
  --query "value[?displayName=='MyWarehouse'].id" --output tsv

監視クエリを実行する

fabric-sqlendpoint-execute_query(
  workspaceId: "aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee",
  itemId: "11111111-2222-3333-4444-555555555555",
  query: "SELECT TOP 5 * FROM queryinsights.long_running_queries ORDER BY last_run_total_elapsed_time_ms DESC"
)

追加の接続設定は不要です — 認証は MCP プロトコルによって透過的に処理されます。

---

パフォーマンス分析

すべての SQL クエリ、パラメーター、戻りフィールド、および応答形式については、query-reference.mdを参照してください。

長時間実行クエリの概要

queryinsights.long_running_queries から最も遅いクエリを見つけます。SQL と書式については、query-reference.md § 長時間実行クエリの概要を参照してください。

リソース消費量の多いクエリ

queryinsights.exec_requests_history から CPU とストレージを多く消費するクエリを見つけます。SQL、しきい値、および書式については、query-reference.md § リソース消費量の多いクエリを参照してください。

推奨しきい値：

• リモートスキャン > 1,000 MB → データレイアウトを確認し、クラスタリングを検討します
• CPU > 5,000,000 ms → クエリロジックを確認します
• 経過時間 > 300,000 ms → 結合、フィルター、統計情報を確認します
• 参考：パフォーマンスのガイドライン

上位ユーザーの分析情報

ユーザーアクティビティとクエリパターンを分析します。SQL と分類ロジックについては、query-reference.md § 上位ユーザーの分析情報を参照してください。

直近の期間とベースラインを比較する

直近の期間と過去のベースラインを比較して、パフォーマンスの低下を検出します。SQL と書式については、query-reference.md § 直近の期間とベースラインを比較するを参照してください。

最近のクエリ

最も最近実行されたクエリを取得します。SQL については、query-reference.md § Recent Queries を参照してください。

クエリパターンの検索

テーブル名、列、またはキーワードで過去のクエリパターンを検索します。SQL については、query-reference.md § Search Query Patterns を参照してください。

---

詳細な診断

診断用の SQL クエリはすべて query-reference.md にあります。

長時間実行クエリの実行プランを分析する

SQL については、query-reference.md § Long-Running Query Analysis を参照してください。

分析のガイダンス — 遅いクエリを確認する際は、次の点を確認してください。

• data_scanned_remote_storage_mb が大きい → データレイアウトの問題です（OPTIMIZE を実行し、クラスタリングを検討してください）
• 経過時間に対して allocated_cpu_time_ms が大きい → CPU バウンドです（JOIN を簡素化し、列を減らしてください）
• 経過時間は長いものの CPU 使用率が低い → リソース待ちです（負荷が高い時間帯がないか確認してください）

負荷が高い時間帯のクエリを分析する

queryinsights.sql_pool_insights を使用して SQL プールの負荷イベントを特定し、その時間帯に実行された最も負荷の高いクエリと関連付けます。2 ステップの SQL については、query-reference.md § Pressure Window Analysis を参照してください。

使用方法： ステップ 1 では、window_start と window_end のタイムスタンプを含む負荷の高い時間帯が返されます。ステップ 2 の WHERE 句に、これらの実際のタイムスタンプ値を入力すると、重複するクエリを特定できます。

全般的な推奨事項 — 負荷の集計分析に基づきます。

• SELECT プールの負荷が高い場合 → 読み取り中心のワークロードです。キャッシュと列の絞り込みを提案してください
• NONSELECT プールの負荷が高い場合 → 書き込み中心です。バッチ処理と COPY INTO を提案してください
• 負荷の合計が 60 分を超える場合 → キャパシティのスケーリング、またはワークロードの時間差実行を提案してください

クエリキャッシュのウォーム状態を分析する

SQL については、query-reference.md § Cache Warmth Analysis を参照してください。

分類ロジック — 各実行について、total_mb = remote + memory + disk を計算します。

• result_cache_hit = 1 → キャッシュ済み
• remote_mb / total_mb > 0.8 → コールド（80% 超がリモートストレージから）
• (memory_mb + disk_mb) / total_mb > 0.8 → ウォーム（80% 超がキャッシュから）

推奨事項：

• コールド実行が 50% を超える場合 → 結果セットのキャッシュを有効にします：ALTER DATABASE SET RESULT_SET_CACHING ON;
• 常にコールドになるパターン → キャッシュキーを無効化する GETDATE()／GETUTCDATE() や揮発性関数がないか確認してください

クラスターキーを推奨する

SQL については、query-reference.md § Cluster Key Recommendations を参照してください。

主なルール：

• クラスタリングによる効果があるのは WHERE 述語のみです。等価条件の JOIN ON 条件には効果がありません
• 中～高カーディナリティの列（異なる値が多い列）を優先してください
• クラスタリング列は最大 4 列です
• WITH (CLUSTER BY (...)) を指定した CTAS を使用してください。ALTER TABLE はサポートされていません

クラスタリングの適用方法 — CTAS の作成、sp_rename によるテーブルの入れ替え、検証用 SQL については、query-reference.md § Cluster Key Recommendations を参照してください。

注： Fabric は ALTER TABLE SET DATA_CLUSTERING_KEY または RENAME OBJECT をサポートしていません。テーブルを入れ替える場合は、必ず WITH (CLUSTER BY (...)) を指定した CTAS と sp_rename を使用してください。

---

Fabric DW の制約

Fabric Data Warehouse でサポートされていない機能は、絶対に推奨しないでください。 最適化の提案を行う前に、必ずこの一覧を確認してください。

推奨しないもの	理由	代わりに推奨するもの
非クラスター化インデックス	サポートされていません	V-Order、列のプルーニング、述語プッシュダウン
マテリアライズドビュー	サポートされていません	標準ビューまたは結果セットのキャッシュ
インデックスヒント（FORCESEEK/FORCESCAN）	サポートされていません	クエリ構造の簡素化
複数列統計	サポートされていません	キー列の単一列統計
ALTER TABLE SET DATA_CLUSTERING_KEY	サポートされていません	WITH (CLUSTER BY (...)) を使った CTAS
RENAME OBJECT	サポートされていません	EXEC sp_rename 'schema.old', 'new'
分離レベルの変更	スナップショットのみ	Fabric はスナップショット分離のみを使用します
CREATE USER	サポートされていません	Fabric ワークスペースでユーザーを管理します
トリガー	サポートされていません	アプリケーションロジックまたは Fabric パイプライン
再帰 CTE	サポートされていません	反復的なアプローチ
「Enable Query Insights」設定	Query Insights は常に有効です。設定項目はありません	アクセスが拒否された場合、ユーザーにはワークスペースの管理者またはメンバーのロールが必要です

---

エージェントワークフロー

ワークフロー 1：「ウェアハウスの動作が遅いのはなぜですか？」

1. 負荷イベントを確認する → 負荷ウィンドウ分析クエリを実行します（過去 24 時間）
2. 最も負荷の高いクエリを特定する → リソース消費量上位のクエリを実行します（過去 1 時間）
3. 遅いクエリを分析する → 長時間実行クエリの分析を実行します
4. キャッシュの動作を確認する → キャッシュのウォーム状態の分析を実行します（過去 24 時間）
5. クラスター化を推奨する → クラスターキーの推奨クエリを実行します

ワークフロー 2：「パフォーマンスは低下しましたか？」

1. ベースラインと比較する → 最近の状態とベースラインの比較を実行します（1 時間と 7 日間）
2. 新たに遅くなったクエリを特定する → 長時間実行クエリの概要を実行します（上位 5 件）
3. ユーザーのパターンを確認する → 上位ユーザーのインサイトを実行します（過去 24 時間）

ワークフロー 3：「ウェアハウスを最適化してください」

1. ベストプラクティスを確認する → SQLDW-CONSUMPTION-CORE.md § Performance: Best Practices and Troubleshooting を参照します
2. 最適化対象を特定する → リソース消費量上位のクエリを実行します（過去 24 時間）
3. クラスター化を推奨する → クラスターキーの推奨クエリを実行します
4. コールドスタートクエリを分析する → キャッシュのウォーム状態の分析を実行します

ワークフロー 4：「どのようなクエリが実行されていますか？」

1. 最近のアクティビティ → 最近のクエリを実行します（上位 10 件）
2. ユーザーのパターン → 上位ユーザーのインサイトを実行します（過去 24 時間）
3. 特定のパターンを検索する → 検索語を指定してクエリパターン検索を実行します

---

ベストプラクティス

Fabric DW の包括的なベストプラクティスについては、SQLDW-CONSUMPTION-CORE.md § Performance: Best Practices and Troubleshooting および Fabric のガイドラインを参照してください。

監視に関するベストプラクティス：

• まず広く確認し、その後詳しく調べる — 詳細な診断を行う前に、長時間実行クエリの概要とベースライン比較から始めます
• ボトルネックを推測するのではなく、根本原因の分析に負荷ウィンドウ分析を使用します
• Query Insights で追跡できるよう、すべてのエージェントクエリに OPTION (LABEL = 'AGENTCLI_MONITOR_...') のラベルを付けます
• クラスターキーには中～高カーディナリティの列を優先します — 低カーディナリティの列では、ファイルスキップの効果が限られます
• クラスターキー候補を特定するには WHERE 述語を使用します — 等価 JOIN ON 条件では、クラスター化の効果は得られません
• CTAS の後は、sys.index_columns.data_clustering_ordinal をクエリして、クラスター化が行われていることを必ず確認します
• クエリが本質的に遅いと判断する前に、コールドキャッシュとウォームキャッシュを確認します — 初回実行はコールドスタートの場合があります
• 調査対象に合わせて時間範囲（DATEADD パラメーター）を調整します — 根拠のない時間範囲をデフォルトにしないでください

---

注意点、ルール、トラブルシューティング

一般的な CLI の注意点（接続、認証、シェルでのエスケープ）については、COMMON-CLI.md § 注意点とトラブルシューティングを参照してください。 T-SQL／プラットフォームに関する注意点については、SQLDW-CONSUMPTION-CORE.md § 注意点とトラブルシューティングのリファレンスを参照してください。

必ず行うこと

• 最適化を推奨する前に、必ずFabric DW の制約を確認してください
• クラスタリングを推奨する場合は、ALTER TABLE ではなく、WITH (CLUSTER BY (...)) を指定した CTAS を使用するようユーザーに案内してください
• 実際のクエリ出力を報告してください。結果を捏造したり、推測したりしないでください
• Query Insights の追跡用に、OPTION (LABEL = 'AGENTCLI_MONITOR_...') でクエリにラベルを付けてください
• 最初の操作の前に、fabric-sqlendpoint-execute_query MCP ツールが利用可能か確認してください

推奨事項

• 診断を掘り下げる前に、高レベルのクエリ（長時間実行の概要、ベースラインとの比較）から始めてください
• ボトルネックを推測するのではなく、根本原因の分析にはプレッシャーウィンドウ分析を使用してください
• 包括的な調査のため、エージェント型ワークフローの複数のクエリを組み合わせてください
• ユーザーの依頼に応じて、時間枠（DATEADD パラメーター）を調整してください
• レート制限を守るため、関連する診断クエリをまとめて呼び出し回数を減らしてください

避けること

• Fabric でサポートされていない機能（非クラスター化インデックス、マテリアライズドビュー、インデックスヒント、トリガー）を推奨すること
• Query Insights を「有効化」または「オンにする」必要があると提案すること。queryinsights ビューは常に利用可能です。権限エラーは、ワークスペースロールが不十分であることを示します（Admin または Member が必要です）
• workspaceId と itemId を確認せずに監視クエリを実行すること
• 診断クエリを実行せずに、パフォーマンス低下の根本原因を推測すること
• 監視クエリで SELECT * を使用すること。必ず列を個別に指定してください
• クエリで GO 区切り文字や sqlcmd メタコマンドを使用すること（MCP ツールが受け付けるのは単一バッチのみです）
• TOP N を指定せずに、件数を制限しないクエリを実行すること（10,000 行の上限が適用されます）

トラブルシューティング（監視固有）

一般的な接続／認証のトラブルシューティングについては、COMMON-CLI.md § 注意点とトラブルシューティングを参照してください。

症状	原因	対処方法
Invalid object name 'queryinsights...'	新しいウェアハウスの作成から 2 分未満	約 2 分待ちます
queryinsights.* に対する権限エラー	ワークスペースロールが不十分	Admin または Member ロールが必要です
queryinsights ビューにデータがない	最近のクエリアクティビティがない、または 15 分未満の遅延	クエリ完了後 15 分待ちます
データは存在するが行がない	RLS によるフィルタリング	USER_NAME() を確認し、RLS ポリシーを検証します
fabric-sqlendpoint-execute_query ツールを利用できない	MCP サーバーが登録されていない	ユーザーが Fabric SQL Endpoint MCP サーバーを追加する必要があります
HTTP 429 レート制限	1 分間の呼び出し回数が多すぎる	60 秒待つか、クエリをまとめます
クエリのタイムアウト（300s）	診断が複雑	より厳密な DATEADD で時間枠を絞り込みます

---

例

遅いクエリを見つける

ユーザー:「ウェアハウス内で最も遅いクエリは何ですか？」

エージェント: fabric-sqlendpoint-execute_query を使用して、長時間実行クエリの概要を実行します。

fabric-sqlendpoint-execute_query(workspaceId, itemId,
  "SELECT TOP 5
      left(last_run_command, 80) AS query_preview,
      number_of_runs,
      last_run_total_elapsed_time_ms,
      median_total_elapsed_time_ms
   FROM queryinsights.long_running_queries
   ORDER BY median_total_elapsed_time_ms DESC")

最も遅いクエリの上位 5 件は次のとおりです。

1. SELECT * FROM FactSales JOIN DimCustomer... — 12 回実行され、直近の実行時間は 45,200 ms（中央値 38,500 ms）でした
2. SELECT region, SUM(amount)... — 8 回実行され、直近の実行時間は 32,100 ms（中央値 29,000 ms）でした ...

パフォーマンス低下を診断する

ユーザー:「私のウェアハウスは先週より遅くなっていますか？」

エージェント: ベースライン比較クエリを実行し、次の結果を提示します。

パフォーマンス比較（直近 1 時間と過去 7 日間のベースライン）：

• 経過時間：平均 2,450 ms → 平均 4,100 ms（+67.3%）
• CPU 消費量：1,200 ms → 2,800 ms（+133.3%）
• スキャンされたデータ：450 MB → 480 MB（+6.7%）

大幅な性能低下を検出しました。プレッシャーイベントを確認し、負荷の最も高いクエリを分析します……

続けて、プレッシャーウィンドウとリソース消費者のクエリを実行します。

クラスタリングの推奨事項を取得する

ユーザー：「どのテーブルを、どの列でクラスタリングすべきですか？」

**エージェント：**クラスタリングキーの推奨クエリを実行し、次の結果を提示します。

推奨されるクラスタリングキー：

テーブル	推奨列	行数	スキャン合計（MB）
dbo.FactSales	SaleDate, Region	50M	12,500 MB
dbo.FactInventory	ProductID, WarehouseID	12M	3,200 MB

クラスタリングを適用するには、CTAS を使用します。

CREATE TABLE dbo.FactSales_clustered
WITH (CLUSTER BY (SaleDate, Region))
AS SELECT * FROM dbo.FactSales;