具體化檢視限制和已知問題
具體化檢視來源
- 具體化檢視的來源資料表:
- 必須是數據直接內嵌、使用 更新原則或 從查詢命令擷取的數據表。
- 只有在使用 屬性做為移動範圍命令的一部分時
setNewIngestionTime
,才支援使用其他數據表或取代其他數據表到具體化檢視之源數據表的範圍, (參考 .move extents 和 .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 原則 , (預設會啟用它) 。
- 具體化檢視的源數據表不能是具有 限制檢視取原則的數據表。
- 除非第一個具體化檢視的類型
take_any(*)
為匯總,否則無法在另一個具體化檢視之上建立具體化檢視。 請參閱 具體化檢視,而非具體化檢視。 - 無法透過 外部數據表定義具體化檢視。
警告
- 如果具體化檢視的來源資料表變更或資料的變更導致具體化檢視查詢與預期具體化檢視的架構不相容,系統就會自動停用具體化檢視。
- 若要避免這個錯誤,具體化檢視查詢必須具決定性。 例如,bag_unpack 或 pivot 外掛程式會導致不具決定性的架構。
- 使用
arg_max(Timestamp, *)
彙總且當autoUpdateSchema
為 false 時,對來源資料表所做的變更也會導致架構不符。- 將檢視查詢定義為
arg_max(Timestamp, Column1, Column2, ...)
或使用autoUpdateSchema
選項,以避免此失敗。
- 將檢視查詢定義為
- 當來源資料表中的資料行卸載時,使用
autoUpdateSchema
可能會導致無法復原的資料遺失。 - 使用 MaterializedViewResult 度量監視自動停用具體化檢視。
- 修正不相容問題之後,應該使用 啟用具體化檢視命令明確地重新啟用檢視 。
從源數據表擷取或卸除的記錄影響
- 具體化檢視只會處理內嵌至來源資料表的新記錄。 透過執行 數據清除/虛刪除/卸除範圍,或因為 保留 原則或任何其他原因而移除源數據表的記錄,不會影響具體化檢視。
- 具體化檢視有自己的保留原則,與來源資料表的保留原則無關。 具體化檢視可能包含源數據表中不存在的記錄。
追蹤者資料庫
- 無法在 追蹤資料庫中建立具體化檢視。 追蹤者資料庫是唯讀的,而具體化檢視則需要寫入作業。
- 您可以從其追蹤者查詢領導者資料庫上定義的具體化檢視,就像領導者中的任何其他資料表一樣。
- 使用領導者叢集來監視追蹤者資料庫具體化檢視。 如需詳細資訊,請參閱 後續資料庫中的具體化檢視。
其他
- 資料指標函數不能用在具體化檢視上。
- 不支援從具體化檢視連續匯出。
意見反應
https://aka.ms/ContentUserFeedback。
即將登場:在 2024 年,我們將逐步淘汰 GitHub 問題作為內容的意見反應機制,並將它取代為新的意見反應系統。 如需詳細資訊,請參閱:提交並檢視相關的意見反應