累加式重新整理和即時資料疑難排解
實作累加式重新整理和即時資料解決方案有兩個階段，第一個階段是在 Power BI Desktop 中設定參數、篩選和定義原則，第二個階段是服務中的初始語意模型重新整理作業和後續重新整理。 本文分別討論了這些階段的疑難排解。
在 Power BI 服務中對資料表進行分割後，請記住，也藉由 DirectQuery 取得即時資料的已累加式重新整理的資料表現在在混合式模式中作業，表示它們在匯入和 DirectQuery 模式下作業。 任何與這種已累加式重新整理的混合式資料表有關聯性的資料表都必須使用 [雙重] 模式，以便它們可以在匯入和 DirectQuery 模式使用，而不會降低效能。 此外，報表視覺效果可能會快取結果，以避免將査詢傳送回資料來源，這將封鎖資料表即時取得最新資料更新。 最後的疑難排解區段涵蓋了這些混合式模式問題。
在對累加式重新整理和即時資料進行疑難排解之前，請務必檢閲模型和即時資料的累加式重新整理以及設定累加式重新整理和即時資料中的分步資訊。
在 Power BI Desktop 中設定
設定累加式重新整理和即時資料時發生的大多數問題都與查詢折疊有關。 如模型累加式重新整理概觀 - 支援的資料來源中所述，您的資料來源必須支援查詢折疊。
問題：載入資料耗時太長
在 Power Query 編輯器中，選取 [套用] 後，載入資料會佔用大量時間和電腦資源。 潜在的原因有幾個。
原因：資料類型不符
此問題可能是由於資料類型不符造成的，其中 RangeStart 和 RangeEnd 參數所需的資料類型是 Date/Time，但套用篩選的資料表日期列不是 Date/Time 資料類型，反之亦然。 參數資料類型和篩選的資料資料行都必須是 Date/Time 資料類型，格式必須相同。 如果不是，則無法折疊査詢。
解決方案：驗證資料類型
驗證累加式重新整理資料表的日期/時間資料行是否為 Date/Time 資料類型。 如果您的資料表不包含 Date/Time 資料類型的資料行，而是使用整數資料類型，則可以建立函式，其將 RangeStart 和 RangeEnd 參數中的日期/時間值轉換為與資料來源資料表的整數 surrogate 索引鍵相符。 若要深入了解，請參閱設定累加式重新整理 - 將 DateTime 轉換為整數。
原因：資料來源不支援查詢折疊
如模型的累加式重新整理和即時資料 - 需求中所述，累加式重新整理是為支援查詢折疊的資料來源設計的。 在發佈至服務之前，請確保在 Power BI Desktop 中折疊資料來源査詢，因為這可能會使查詢折疊問題變得更加複雜。 當在累加式重新整理原則中包含即時資料時，這種方法尤為重要，因為即時 DirectQuery 分割區需要査詢折疊。
解決方案：驗證和測試査詢
在大多數情况下，累加式重新整理原則對話方塊中會顯示警告，指示對資料來源執行的査詢是否不支援查詢折疊。 然而，在某些情况下，可能需要進一步確保查詢折疊是可能的。 如果可能，請使用 SQL Profiler 等工具監視傳遞給資料來源的査詢。 具有根據 RangeStart 和 RangeEnd 的篩選之査詢必須在單一査詢中執行。
您還可以在 RangeStart 和 RangeEnd 參數中指定不超過幾千列的短日期/時間週期。 如果將篩選後的資料從資料來源載入至模型需要很長時間並且為流程密集型，這可能表示査詢沒有被折疊。
如果您確定査詢未被折疊，請參閱 Power BI Desktop 中的查詢折疊指導和 Power Query 查詢折疊，以協助確定可能封鎖查詢折疊的原因以及資料來源如何甚至是否可以支援查詢折疊。
服務中的語意模型重新整理
服務中累加式重新整理問題之疑難排解因模型發佈至的容量類型而異。 Premium 容量上的語意模型支援使用 SQL Server Management Studio (SSMS) 等工具檢視和選擇性重新整理單一分割區。 另一方面，Power BI Pro 模型不提供透過 XMLA 端點的工具存取，因此解决累加式重新整理問題可能需要更多的試用和錯誤。
問題：初始重新整理逾時
共用容量的 Power BI Pro 模型之排程重新整理時間限制為兩小時。 對於 Premium 容量的模型，此時間限制增至五個小時。 資料來源系統還可能會加諸査詢傳回大小限制或査詢逾時。
原因：資料來源査詢未被折疊
雖然查詢折疊的問題通常可以在發佈至服務之前在 Power BI Desktop 中確定，但模型重新整理査詢可能沒有折疊，導致重新整理時間過長和査詢 mashup 引擎資源使用率過高。 這種情況的發生是因為為模型中的每個分割區建立了一個査詢。 如果査詢沒有被折疊，並且資料來源沒有對資料進行篩選，則引擎會嘗試篩選資料。
解決方案：驗證查詢折疊
在資料來源處使用追蹤工具來確定為每個分割區傳遞的査詢是包含根據 RangeStart 和 RangeEnd 參數之篩選的單一査詢。 如果不是，請驗證在將少量篩選後的資料載入 Power BI Desktop 模型中時，查詢折疊是否發生在該模型中。 如果不是，請先在模型中修正它，對模型執行僅中繼資料更新 (透過使用 XMLA 端點)，或者如果是共用容量上的 Power BI Pro 模型，請删除服務中不完整的模型，重新發佈，然後重試初始重新整理作業。
如果您確定査詢沒有被折疊，請參閱 Power BI Desktop 中的查詢折疊指導和 Power Query 査詢折疊，以協助識別可能封鎖査詢折疊的原因。
原因：載入至分割區中的資料太大
解決方案：减小模型大小
在許多情况下，逾時是由於必須査詢和載入至模型分割區中的資料量超過了容量所規定的時間限制造成的。 减小模型的大小或複雜度，或考慮將模型分解為更小的部分。
解決方案：啟用大型模型儲存體格式
對於發佈至 Premium 容量的模型，如果模型增長超過 1 GB 或更多，您可以在服務中執行第一次重新整理作業之前啟用大型模型儲存體格式，以提高重新整理作業效能，並確保模型不會超出最大大小限制。 若要深入了解，請參閱 Power BI Premium 中的大型模型。
解決方案：啟動初始重新整理
對於發佈至 Premium 容量的模型，您可以啟動初始重新整理作業。 啟動允許服務為模型建立資料表和分割區物件，但不能將歷程資料載入和處理至任何分割區中。 若要深入了解，請參閱進階累加式重新整理 - 防止初始完全重新整理時逾時。
原因：資料來源査詢逾時
査詢可以受限於資料來源預設使用時間限制。
解決方案：覆寫査詢運算式中的時間限制
許多資料來源允許在査詢運算式中覆寫時間限制。 若要深入了解，請參閱模型的累加式重新整理 - 時間限制。
問題：由於值重複，重新整理失敗
原因：張貼日期已變更
藉由重新整理作業，只有在資料來源處發生變更的資料才會在模型中重新整理。 由於資料由日期分割，建議不要變更張貼 (交易) 日期。
如果日期意外變更，則可能會發生兩個問題：使用者注意到歷程資料中的一些總計發生了變更 (本不應該發生)，或者在重新整理期間傳回了錯誤，表示唯一值實際上並不唯一。
對於後者，當設定了累加式重新整理的資料表與另一個資料表作為 1 側以 1:N 關聯性使用並且應該具有唯一值時，可能會發生這種情況。 當為特定識別碼變更資料時，該識別碼會出現在另一個分割區中，引擎會偵測到值不是唯一的。
解決方案：重新整理特定分割區
如果商務需要變更日期中的一些過去資料，一種可能的解決方案是使用 SSMS 重新整理從變更位置到目前重新整理分割區的所有分割區，從而保持關聯性的 1 側唯一。
問題：資料被截斷
原因：已超過資料來源査詢限制
某些資料來源，如 Azure Data Explorer、Log Analytics 和 Application Insights，對可傳回用於外部査詢的資料之限制為 64 MB (壓縮)。 Azure Data Explorer 可能會傳回明確錯誤，但對於 Log Analytics 和 Application Insights 等其他工具，傳回的資料會被截斷。
解決方案：指定較小的重新整理和儲存週期
在原則中指定較小的重新整理和儲存週期。 例如，如果您指定了一年的重新整理期，但傳回了査詢錯誤或傳回的資料被截斷，請嘗試 12 個月的重新整理週期。 您想要確保根據重新整理和儲存週期對目前重新整理分割區或任何歷程分割區的査詢傳回之資料不超過 64 MB。
問題：由於分割區索引鍵衝突，重新整理失敗
原因：資料來源日期資料行中的日期已更新
日期資料行上的篩選用於在 Power BI 服務中將資料動態分割為週期範圍。 累加式重新整理設計目的並不是為了支援在來源系統中更新篩選日期資料行的案例。 更新會被解譯為插入及刪除，而不是實際的更新。 如果删除發生在歷程範圍內而不是累加範圍內，則不會被拾取，這可能會導致分割區索引鍵衝突導致資料重新整理失敗。
服務中的混合式模式 (預覽)
當 Power BI 套用具有即時資料的累加式重新整理原則時，它會將累加式重新整理的資料表轉換為在匯入和 DirectQuery 模式下執行的混合式資料表。 請注意範例資料表之以下分割區清單末尾的 DirectQuery 分割區。 DirectQuery 分割區的存在對査詢此資料表之相關資料表和報表視覺效果有影響。
問題：査詢效能較差
原因：相關資料表未處於 [雙重] 模式
在匯入和 DirectQuery 模式下執行之混合式資料表要求任何相關資料表在 [雙重] 模式下執行，以便其可以作為快取或不快取，具體取決於提交給 Power BI 模型的査詢之內容。 [雙重] 模式使 Power BI 能够减少模型中有限關聯性的數量，並產生高效的資料來源査詢，以確保良好的效能。 無法將有限的關聯性推送至需要 Power BI 擷取超過所需資料的資料來源。 因為雙重資料表可以作為 DirectQuery 或匯入資料表使用，所以可避免這種情況。
解決方案：將相關資料表轉換為 [雙重] 模式
設定累加式重新整理原則時，當您選取使用 DirectQuery 即時取得最新資料 (僅 Premium) 時，Power BI Desktop 會提醒您將任何相關資料表切換至 [雙重] 模式。 此外，請確保在模型檢視中檢閲所有現有資料表關聯性。
目前在 DirectQuery 模式下執行的資料表可以輕鬆切換至 [雙重] 模式。 在資料表屬性的 [進階] 下，從儲存模式清單方塊中選取 [雙重]。 然而，目前以匯入模式執行的資料表需要手動執行。 「雙重」資料表具有與 DirectQuery 資料表相同的功能性限制。 因此，Power BI Desktop 無法轉換匯入資料表，因為它們可能依賴於 [雙重] 模式中不可用的其他功能。 您必須在 DirectQuery 模式下手動重新建立這些資料表，然後將其轉換為 [雙重] 模式。 若要深入了解，請參閱 Power BI Desktop 中的管理儲存體模式。
問題：報表視覺效果不顯示最新資料
原因：Power BI 快取查詢結果可提高效能並减少後端負載
Power BI 預設快取查詢結果，以便快速處理報表視覺效果的査詢 (即使它們根據 DirectQuery)。 避免不必要的資料來源査詢可以提高效能並减少資料來源負載，但這也可能表示來源處的最新資料變更不包括在結果中。
解決方案：設定自動頁面重新整理
若要繼續從來源取得最新的資料變更，請在 Power BI 服務中為您的報表設定自動頁面重新整理。 自動頁面重新整理可以以固定的間隔執行，例如五秒或十分鐘。 當到達該特定間隔時，該頁面中的所有視覺效果都會將更新查詢傳送至資料來源，並據以更新。 或者，您可以根據偵測到的資料變更重新整理頁面上的視覺效果。 此方法需要變更偵測量值，然後 Power BI 使用它來輪詢資料來源以尋找變更。 僅在 Premium 容量的工作區中支援變更偵測。 若要深入了解，請參閱 Power BI 中的自動頁面重新整理。