具體化檢視限制和已知問題

適用於： ✅Microsoft網狀架構✅Azure 數據總管

具體化檢視來源

具體化檢視的源數據表：
- 必須是數據直接內嵌、使用更新原則或從查詢命令內嵌的數據表。
  - 只有在使用 setNewIngestionTime 屬性做為移動範圍命令的一部分時，才支援使用從其他數據表移至具體化檢視之源數據表的範圍（如需詳細資訊，請參閱 .move 範圍和 .replace extents 命令）。
  - 將範圍移至具體化檢視的源數據表，但未使用 setNewIngestionTime 可能會失敗，並出現下列其中一個錯誤：
    - Cannot drop/move extents from/to table 'TableName' since Materialized View 'ViewName' is currently processing some of these extents.
    - Cannot move extents to 'TableName' since materialized view 'ViewName' will not process these extents (can lead to data loss in the materialized view).
具體化檢視的源數據表必須啟用 IngestionTime 原則。默認會啟用此原則。
如果具體化檢視使用 lookback （請參閱支援的屬性）， ingestion_time() 則必須在具體化檢視的查詢中保留。 mv-expand 或 pivot 外掛程式等運算符不會保留，ingestion_time()因此無法在具體lookback化檢視中使用。
具體化檢視的源數據表不能是具有限制檢視取原則的數據表。
除非第一個具體化檢視的類型 take_any(*) 為匯總，否則無法在另一個具體化檢視之上建立具體化檢視。如需具體化檢視，請參閱具體化檢視。
具體化檢視無法透過外部資料表定義。

警告

如果具體化檢視的源數據表變更，或數據變更會導致具體化檢視查詢與預期的具體化檢視架構不相容，系統會自動停用具體化檢視。
- 若要避免此錯誤，具體化檢視查詢必須具決定性。例如， bag_unpack 或樞紐外掛程式會導致不具決定性的架構。
- 使用 arg_max(Timestamp, *) 匯總和 false 時 autoUpdateSchema ，源數據表的變更也可能會導致架構不符。
  - 藉由將檢視查詢 arg_max(Timestamp, Column1, Column2, ...)定義為，或使用 autoUpdateSchema 選項來避免此失敗。
使用 autoUpdateSchema 可能會導致卸除源數據表中的數據行時無法復原的數據遺失。
使用MaterializedViewResult計量監視具體化檢視的自動停用。
修正不相容問題之後，應該使用啟用具體化檢視命令明確地重新啟用檢視。