具体化されたビューを監視する

[アーティクル]
02/05/2025

適用対象: ✅Microsoft Fabric✅Azure データエクスプローラー

次の方法で、具体化されたビューの正常性を監視します:

Azure Monitorを使用して、Azure portal で具体化されたビューメトリックを監視します。具体化されたビューの経過時間メトリック (MaterializedViewAgeSeconds) をプライマリメトリックとして使用して、ビューの鮮度を監視します。

Microsoft Fabric ワークスペース具体化されたビューメトリックを監視します。具体化されたビューの経過時間メトリックを使用し、ビューの鮮度を監視するための主要なメトリックとして MaterializedViewAgeSeconds します。詳細については、「ワークスペースで監視を有効にする」を参照してください。

.show materialized-viewを使用して、IsHealthy プロパティを監視します。
.show materialized-view failuresを使用して故障を確認します。

Note

具体化は、一定の故障がある場合でも、データをスキップすることはありません。ビュー*は常に、ソース* テーブル*内のすべてのレコード*に基づき、クエリ*の最新のスナップショットを返すことが保証されます。一定のエラーによりクエリのパフォーマンスが大幅に低下しますが、ビュークエリで誤った結果が発生することはありません。

異常のある具体化されたビュー*のトラブルシューティング

MaterializedViewAge メトリックが絶えず増加し、MaterializedViewHealth メトリックでビューが異常であることが示されている場合は、次の推奨事項に従って根本原因を特定します。

クラスター上の具体化されたビューの数と、具体化されたビューの現在の容量を確認します。
```
.show capacity 
| where Resource == "MaterializedView"
| project Resource, Total, Consumed
```
出力

資源トータル消費

MaterializedView 1 0
- 同時に実行できる具体化されたビューの数は、Total 列に表示される容量によって異なりますが、Consumed 列には現在実行中の具体化されたビューの数が表示されます。具体化されたビューの容量ポリシーを使用して、同時実行操作の最小数と最大数を指定し、システムの既定のコンカレンシーレベルをオーバーライドできます。システムは、クラスターの使用可能なリソースに基づいて、Totalに示されている現在のコンカレンシーを決定します。次の例では、システムの決定をオーバーライドし、最小同時操作を 1 から 3 に変更します。
```
.alter-merge cluster policy capacity '{  "MaterializedViewsCapacity": { "ClusterMinimumConcurrentOperations": 3 } }'
```
- このポリシーを明示的に変更する場合は、クラスターの正常性を監視し、他のワークロードがこの変更の影響を受けないことを確認します。

資源	トータル	消費
MaterializedView	1	0

を使用して具体化プロセス中にエラーが発生しているかどうかを確認します。具体化されたビューのエラー表示します。
- エラーが永続的な場合、マテリアライズドビューは自動的に無効になります。無効になっているかどうかを確認するには、.show materialized-view コマンドを使用して、IsEnabled 列の値が falseされているかどうかを確認します。次に、.show journal コマンドを使用して、無効なイベントの履歴を確認します。永続的なエラーの例として、具体化されたビューと互換性のないソーステーブルスキーマの変更があります。詳細については、「.create materialized-view コマンドを参照してください。
- 障害が一時的な場合、システムは自動的に操作を再試行します。ただし、エラーにより具体化が遅れ、具体化されたビューの経過時間が長くなる可能性があります。この種類のエラーは、メモリ制限に達したときやクエリタイムアウトが発生した場合などに発生します。一時的な障害をトラブルシューティングするその他の方法については、次の推奨事項を参照してください。
.show commands-and-queries コマンドを使用して、具体化プロセスを分析します。 Databasename と viewName を置き換えて、特定のビューをフィルター処理します。
```
.show commands-and-queries 
| where Database  == "DatabaseName" and ClientActivityId startswith "DN.MaterializedViews;ViewName;"
```
- MemoryPeak 列のメモリ消費量を調べて、メモリ制限に達したために失敗した操作 (ランナウェイクエリなど) を特定します。既定では、具体化プロセスはノードあたり 15 GB のメモリピークに制限されます。具体化プロセス中に実行されたクエリまたはコマンドがこの値を超えると、メモリ制限のために具体化が失敗します。ノードあたりのメモリピークを増やすには、$materialized ビューワークロードグループを変更します。次の例では、具体化時にノードあたり最大 64 GB のメモリピークを使用するように、具体化されたビューワークロードグループを変更します。
```
.alter-merge workload_group ['$materialized-views'] ```
{
  "RequestLimitsPolicy": {
    "MaxMemoryPerQueryPerNode": {
      "Value": 68719241216
    }
  }
} 
```
  Note
  
  MaxMemoryPerQueryPerNode は、各ノードで使用可能な合計メモリの 50% を超えることはできません。
- 具体化プロセスがコールドキャッシュに達しているかどうかを確認します。次の例は、具体化されたビューの過去 1 日のキャッシュ統計を示 ViewName。
```
.show commands-and-queries 
| where ClientActivityId startswith "DN.MaterializedViews;ViewName"
| where StartedOn > ago(1d)
| extend HotCacheHits = tolong(CacheStatistics.Shards.Hot.HitBytes), 
         HotCacheMisses = tolong(CacheStatistics.Shards.Hot.MissBytes), 
         HotCacheRetrieved = tolong(CacheStatistics.Shards.Hot.RetrieveBytes), 
         ColdCacheHits = tolong(CacheStatistics.Shards.Cold.HitBytes), 
         ColdCacheMisses = tolong(CacheStatistics.Shards.Cold.MissBytes), 
         ColdCacheRetrieved = tolong(CacheStatistics.Shards.Cold.RetrieveBytes)
| summarize HotCacheHits = format_bytes(sum(HotCacheHits)), 
            HotCacheMisses = format_bytes(sum(HotCacheMisses)),
            HotCacheRetrieved = format_bytes(sum(HotCacheRetrieved)), 
            ColdCacheHits =format_bytes(sum(ColdCacheHits)), 
            ColdCacheMisses = format_bytes(sum(ColdCacheMisses)),
            ColdCacheRetrieved = format_bytes(sum(ColdCacheRetrieved))
```
  出力
  
  HotCacheHits HotCacheMisses HotCacheRetrieved ColdCacheHits ColdCacheMisses ColdCacheRetrieved
  
  26 GB 0 バイト 0 バイト 1 GB 0 バイト 866 MB
  - ビューがホットキャッシュに完全に存在しない場合、具体化でディスクミスが発生し、プロセスが大幅に遅くなる可能性があります。
  - 具体化されたビューのキャッシュポリシーを増やすと、キャッシュミスを回避できます。詳細については、「ホットキャッシュとコールドキャッシュとキャッシュポリシーのと .alter materialized-view policy caching コマンドのをする」を参照してください。
- .show queries コマンドを使用して ScannedExtentsStatistics をチェックして、マテリアライズが古いレコードをスキャンしているかどうかを確認します。スキャンされたエクステントの数が多く、MinDataScannedTime が古い場合は、具体化された のすべて(またはほとんど)をビューの一部 スキャンする必要があります。スキャンは、差分との交差を見つけるために必要です。差分と マテリアライズド パーツの詳細については、「具体化されたビューののしくみ」を参照してください。次の推奨事項では、デルタとの交差部分を最小限に抑えることで、具体化されたサイクルでスキャンされるデータの量を減らす方法を提供します。
具体化サイクルで大量のデータ (コールドキャッシュを含む可能性あり) をスキャンする場合は、具体化されたビュー定義に次の変更を加えるかどうかを検討してください。
- ビュー定義に datetime グループ化キーを含めます。これにより、この列 に遅延到着データがない限り、、スキャンされるデータの量を大幅に削減できます。詳細については、「パフォーマンスのヒント」を参照してください。グループ化キーの更新はサポートされていないため、新しい具体化されたビューを作成する必要があります。
- ビュー定義の一部として lookback を使用します。詳細については、「.create materialized view supported propertiesを参照してください。

HotCacheHits	HotCacheMisses	HotCacheRetrieved	ColdCacheHits	ColdCacheMisses	ColdCacheRetrieved
26 GB	0 バイト	0 バイト	1 GB	0 バイト	866 MB

MaterializedViewResult メトリックまたは IngestionUtilization メトリック InsufficientCapacity 値が表示されているかどうかを確認して、十分なインジェスト容量があるかどうかを確認します。インジェスト容量を増やすには、使用可能なリソース (推奨) をスケーリングするか、インジェスト容量ポリシーを変更します。

MaterializedViewResult メトリックに InsufficientCapacity 値が表示されているかどうかを確認して、十分なインジェスト容量があるかどうかを確認します。使用可能なリソースをスケーリングすることで、インジェスト容量を増やすことができます。

具体化されたビューがまだ異常な場合、サービスには、時間に従ってすべてのデータを具体化するための十分な容量やリソースがありません。次のオプションを検討してください。
- 最小インスタンス数を増やしてクラスターをスケールアウトします。最適化された自動スケールは具体化されたビューを考慮せず、具体化されたビューが異常な場合はクラスターを自動的にスケールアウトしません。具体化されたビューに対応するために、クラスターにより多くのリソースを提供するには、最小インスタンス数を設定する必要があります。
- Eventhouse をスケールアウトして、具体化されたビューに対応するためのより多くのリソースを提供します。詳細については、「最小消費を有効にする」を参照してください。
- 具体化されたビューを複数の小さなビューに分割し、それぞれがデータのサブセットをカバーします。たとえば、具体化されたビューのグループ化キーから、カーディナリティの高いキーに基づいて分割できます。すべてのビューは同じソーステーブルに基づいており、各ビューは SourceTable | where hash(key, number_of_views) == iでフィルター処理されます。ここで、i はセット {0,1,…,number_of_views-1}の一部です。次に、すべての小さい具体化されたビュー共用体をするストアド関数を定義できます。結合されたデータにアクセスするには、クエリでこの関数を使用します。
ビューを分割すると CPU 使用率が増加する可能性がある一方で、具体化サイクルのメモリピークが減少します。メモリの上限を減らすと、メモリ制限のために単一ビューが失敗した場合に役立ちます。

MaterializedViewResultメトリック

MaterializedViewResult メトリックは、具体化サイクルの結果に関する情報を提供し、具体化されたビューの正常性状態の問題を特定するために使用できます。メトリックには、 Database と MaterializedViewName 、および Result ディメンションが含まれます。

Resultディメンションは次のいずれかの値を有します:

成功: 具体化は正常に完了しました。
SourceTableNotFound: 具体化されたビューのソーステーブルが削除されたため、具体化されたビューは自動的に無効になります。
SourceTableSchemaChange: ソーステーブルのスキーマが、具体化されたビュー定義と互換性のない方法で変更されました。具体化されたビュークエリはマテリアライズドビュースキーマと一致しなくなったため、具体化されたビューは自動的に無効になります。

InsufficientCapacity: インジェスト容量不足しているため、インスタンスには具体化されたビューを具体化するための十分な容量ありません。容量不足のエラーは一時的なものである可能性があります。頻繁に繰り返される場合は、インスタンスをスケールアウトするか、ポリシー内の関連する容量を増やしてみてください。

InsufficientCapacity: インジェスト容量がないため、インスタンスには具体化されたビューを具体化するための十分な容量がありません。容量不足のエラーは一時的なものになる可能性があります。頻繁に繰り返される場合は、インスタンスをスケールアウトするか、容量を増やしてみてください。詳細については、「容量サイズを計画する」を参照してください。

InsufficientResources: 具体化されたビューを具体化するのに十分なリソース (CPU/メモリ) がデータベースにありません。リソースエラーが不十分な場合は一時的なものですが、頻繁に繰り返される場合は、スケールアップまたはスケールアウトしてみてください。その他のアイデアについては、「異常な具体化されたビューのトラブルシューティング」を参照してください。

フォロワーデータベースの具体化されたビュー

具体化されたビューは、 follower データベースで定義できます。ただし、これらの具体化されたビューの監視は、具体化されたビューが定義されているリーダーデータベースに基づく必要があります。具体的には、次のように使用します。

具体化されたビューの実行に関連するメトリック (MaterializedViewResult、 MaterializedViewExtentsRebuild) は、リーダーデータベースにのみ存在します。監視 (MaterializedViewAgeSeconds、MaterializedViewHealth、MaterializedViewRecordsInDelta) に関連するメトリックもフォロワーデータベースに表示されます。

.show materialized-view failures コマンドはリーダーデータベースでのみ機能します。

リソース消費量の追跡

具体化されたビュー*のリソース*消費: 具体化されたビュー*の具体化プロセス*によって消費されるリソース*は、.show commands-and-queries コマンドを使用して追跡*できます。次のものを使用して、特定のビュー*のレコード*をフィルタリングします (DatabaseName と ViewName を置換*):

.show commands-and-queries 
| where Database  == "DatabaseName" and ClientActivityId startswith "DN.MaterializedViews;ViewName;"

具体化されたビューをする
具体化されたビューのユースケース

次の方法で共有

具体化されたビューを監視する

異常のある具体化されたビュー*のトラブルシューティング

MaterializedViewResultメトリック

フォロワーデータベースの具体化されたビュー

リソース消費量の追跡

フィードバック

その他のリソース

次の方法で共有

具体化されたビューを監視する

異常のある具体化されたビュー*のトラブルシューティング

MaterializedViewResultメトリック

フォロワー データベースの具体化されたビュー

リソース*消費量の追跡*

関連コンテンツ

フィードバック

その他のリソース

フォロワーデータベースの具体化されたビュー

リソース消費量の追跡