查詢交錯

發行項
12/23/2023

適用于：SQL Server Analysis Services Azure Analysis Services Fabric/Power BI Premium

查詢交錯是表格式模式系統組態，可改善高並行案例中的查詢效能。根據預設，Analysis Services 表格式引擎適用于 CPU 的先進先出 (FIFO) 方式。例如，使用 FIFO 時，如果收到一個資源昂貴且可能緩慢的儲存體引擎查詢，然後接著兩個快速的查詢，則快速查詢可能會遭到封鎖，等待昂貴的查詢完成。下圖顯示此行為，其中顯示 Q1、Q2 和 Q3 作為個別查詢、其持續時間和 CPU 時間。

先入，先出

具有 簡短查詢偏差的查詢 交錯可讓並行查詢共用 CPU 資源，這表示快速查詢不會在慢速查詢後遭到封鎖。完成這三個查詢所需的時間仍然相同，但在我們的範例 Q2 和 Q3 中，在結束之前不會遭到封鎖。短查詢偏差表示快速查詢，由每個查詢在指定時間點已耗用多少 CPU 所定義，可以配置比長時間執行的查詢更高的資源比例。在下圖中，Q2 和 Q3 查詢被視為快速且配置比 Q1 更多的 CPU。

短查詢偏差

查詢交錯的目的是要對隔離執行的查詢產生少量或沒有效能影響;單一查詢仍可使用與 FIFO 模型一樣多的 CPU。

重要的考量

在判斷查詢交錯是否適合您的案例之前，請記住下列事項：

查詢交錯僅適用于匯入模型。這不會影響 DirectQuery 模型。
查詢交錯只會考慮 VertiPaq 儲存引擎查詢所耗用的 CPU。它不適用於公式引擎作業。
單一 DAX 查詢可能會導致多個 VertiPaq 儲存引擎查詢。根據儲存體引擎查詢所耗用的 CPU，DAX 查詢會被視為快速或緩慢。 DAX 查詢是度量單位。
根據預設，重新整理作業會受到保護，免于查詢交錯。長時間執行的重新整理作業會以不同的方式分類為長時間執行的查詢。

設定

若要設定查詢交錯，請設定 Threadpool\SchedulingBehavior 屬性。您可以使用下列值來指定此屬性：

值	描述
-1	自動。引擎會選擇佇列類型。
SSAS 2019) 的 0 (預設值	首先，先 (FIFO) 。
1	短查詢偏差。引擎會在壓力過大時逐漸節流長時間執行的查詢，以利快速查詢。
3 (Azure AS、Power BI、SSAS 2022 和更新版本的預設值)	快速取消的簡短查詢偏差。改善高並行案例中的使用者查詢回應時間。僅適用于 Azure AS、Power BI、SSAS 2022 和更新版本。

目前，只能使用 XMLA 來設定 SchedulingBehavior 屬性。在SQL Server Management Studio中，下列 XMLA 程式碼片段會將SchedulingBehavior屬性設定為1，簡短的查詢偏差。

<Alter AllowCreate="true" ObjectExpansion="ObjectProperties" xmlns="http://schemas.microsoft.com/analysisservices/2003/engine">
  <Object />
  <ObjectDefinition>
    <Server xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:ddl2="http://schemas.microsoft.com/analysisservices/2003/engine/2" xmlns:ddl2_2="http://schemas.microsoft.com/analysisservices/2003/engine/2/2" xmlns:ddl100_100="http://schemas.microsoft.com/analysisservices/2008/engine/100/100" xmlns:ddl200="http://schemas.microsoft.com/analysisservices/2010/engine/200" xmlns:ddl200_200="http://schemas.microsoft.com/analysisservices/2010/engine/200/200" xmlns:ddl300="http://schemas.microsoft.com/analysisservices/2011/engine/300" xmlns:ddl300_300="http://schemas.microsoft.com/analysisservices/2011/engine/300/300" xmlns:ddl400="http://schemas.microsoft.com/analysisservices/2012/engine/400" xmlns:ddl400_400="http://schemas.microsoft.com/analysisservices/2012/engine/400/400" xmlns:ddl500="http://schemas.microsoft.com/analysisservices/2013/engine/500" xmlns:ddl500_500="http://schemas.microsoft.com/analysisservices/2013/engine/500/500">
      <ID>myserver</ID>
      <Name>myserver</Name>
      <ServerProperties>
        <ServerProperty>
          <Name>ThreadPool\SchedulingBehavior</Name>
          <Value>1</Value>
        </ServerProperty>
      </ServerProperties>
    </Server>
  </ObjectDefinition>
</Alter>

重要

需要重新開機伺服器實例。在Azure Analysis Services中，您必須暫停，然後繼續伺服器，有效地重新開機。

其他屬性

在大部分情況下，SchedulingBehavior 是唯一您需要設定的屬性。下列其他屬性的預設值應該適用于大部分具有簡短查詢偏差的案例，但如有需要可以變更這些屬性。除非藉由設定 SchedulingBehavior 屬性來啟用查詢交錯，否則下列屬性 不會有任何作用 。

ReservedComputeForFastQueries - 設定快速查詢的保留邏輯核心數目。所有查詢都會被視為快速，直到其衰減為止，因為它們已用盡特定數量的 CPU。 ReservedComputeForFastQueries 是介於 0 到 100 之間的整數。預設值為 75。

ReservedComputeForFastQueries 的測量單位是核心的百分比。例如，在具有 20 個核心的伺服器上，值為 80，嘗試保留 16 個核心以供快速查詢 (，同時不會執行任何重新整理作業) 。 ReservedComputeForFastQueries 會進位到最接近的核心數目。建議您不要將這個屬性值設定為低於 50。這是因為快速查詢可能會受到影響，而且與功能的整體設計相反。

DecayIntervalCPUTime - 整數，代表查詢在衰減之前花費的毫秒 CPU 時間。如果系統處於 CPU 壓力，則已衰減的查詢僅限於未保留給快速查詢的其餘核心。預設值為 60,000。這代表 1 分鐘的 CPU 時間，而不是經過的行事歷時間。

ReservedComputeForProcessing - 設定每個處理 (資料重新整理) 作業的保留邏輯核心數目。屬性值是介於 0 到 100 之間的整數，預設值為 75 表示。值代表 ReservedComputeForFastQueries 屬性所決定的核心百分比。值為 0 (零) 表示處理作業受限於與查詢相同的查詢交錯邏輯，因此可以衰減。

雖然未執行任何處理作業，但 ReservedComputeForProcessing 沒有任何作用。例如，在具有 20 個核心的伺服器上，值為 80，ReservedComputeForFastQueries 會保留 16 個核心以供快速查詢。在值為 75 的情況下，ReservedComputeForProcessing 接著會保留 12 個核心以供重新整理作業使用，在處理作業執行及取用 CPU 時保留 4 個快速查詢。如下列「 衰減查詢 」一節所述，其餘 4 個核心 (不會保留給快速查詢或處理作業，) 仍會用於快速查詢，並在閒置時進行處理。

這些額外的屬性位於 ResourceGovernance 屬性節點之下。在SQL Server Management Studio中，下列範例 XMLA 程式碼片段會將 DecayIntervalCPUTime 屬性設定為小於預設值的值：

<Alter AllowCreate="true" ObjectExpansion="ObjectProperties" xmlns="http://schemas.microsoft.com/analysisservices/2003/engine">
  <Object />
  <ObjectDefinition>
    <Server xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:ddl2="http://schemas.microsoft.com/analysisservices/2003/engine/2" xmlns:ddl2_2="http://schemas.microsoft.com/analysisservices/2003/engine/2/2" xmlns:ddl100_100="http://schemas.microsoft.com/analysisservices/2008/engine/100/100" xmlns:ddl200="http://schemas.microsoft.com/analysisservices/2010/engine/200" xmlns:ddl200_200="http://schemas.microsoft.com/analysisservices/2010/engine/200/200" xmlns:ddl300="http://schemas.microsoft.com/analysisservices/2011/engine/300" xmlns:ddl300_300="http://schemas.microsoft.com/analysisservices/2011/engine/300/300" xmlns:ddl400="http://schemas.microsoft.com/analysisservices/2012/engine/400" xmlns:ddl400_400="http://schemas.microsoft.com/analysisservices/2012/engine/400/400" xmlns:ddl500="http://schemas.microsoft.com/analysisservices/2013/engine/500" xmlns:ddl500_500="http://schemas.microsoft.com/analysisservices/2013/engine/500/500">
      <ID>myserver</ID>
      <Name>myserver</Name>
      <ServerProperties>
        <ServerProperty>
          <Name>ResourceGovernance\DecayIntervalCPUTime</Name>
          <Value>15000</Value>
        </ServerProperty>
      </ServerProperties>
    </Server>
  </ObjectDefinition>
</Alter>

已衰減的查詢

本節所述的條件約束僅適用于系統處於 CPU 壓力之下時。例如，如果單一查詢在給定時間唯一在系統中執行，則不論它是否已衰減，都可以取用所有可用的核心。

每個查詢可能需要許多儲存體引擎作業。當集區中的查詢核心變成可用時，排程器會根據經過的行事歷時間檢查最舊的執行中查詢，以查看它是否已用盡其 最大核心權利 (MCE) 。如果沒有，則會執行其下一個作業。如果是，則會評估下一個最舊的查詢。查詢 MCE 取決於它已經使用的衰減間隔數目。針對所使用的每個衰減間隔，MCE 會根據下表所示的演算法來減少。這會繼續執行，直到查詢完成、逾時或 MCE 減少為單一核心為止。

在下列範例中，系統有 32 個核心，而系統的 CPU 會受到壓力。

ReservedComputeForFastQueries 為 60 (60%) 。

20 個核心 (19.2 進位) 會保留給快速查詢。
其餘 12 個核心會配置給已衰減的查詢。

DecayIntervalCPUTime 是 60,000 (1 分鐘的 CPU 時間) 。

只要查詢未逾時或完成，查詢的生命週期可能如下所示：

階段	狀態	執行/排程	MCE
0	快速	MCE 是 20 個核心， (保留給快速查詢) 。查詢是以 FIFO 方式執行，與 20 個保留核心中的其他快速查詢有關。 CPU 時間的衰減間隔為 1 分鐘。	20 = MIN (32/2˄0， 20)
1	腐爛	MCE 設定為 12 個核心， (12 個剩餘的核心未保留給快速查詢) 。作業會根據最多 MCE 的可用性來執行。 CPU 時間的衰減間隔為 1 分鐘。	12 = MIN (32/2˄1， 12)
2	腐爛	MCE 設定為 8 個核心， (32 個核心總計) 的四分之一。作業會根據最多 MCE 的可用性來執行。 CPU 時間的衰減間隔為 1 分鐘。	8 = MIN (32/2˄2， 12)
3	腐爛	MCE 設定為 4 個核心。作業會根據最多 MCE 的可用性來執行。 CPU 時間的衰減間隔為 1 分鐘。	4 = MIN (32/2˄3， 12)
4	腐爛	MCE 設定為 2 個核心。作業會根據最多 MCE 的可用性來執行。 CPU 時間的衰減間隔為 1 分鐘。	2 = MIN (32/2˄4， 12)
5	腐爛	MCE 設定為 1 核心。作業會根據最多 MCE 的可用性來執行。當查詢已底部時，不會套用衰減間隔。由於達到至少 1 個核心，因此不會進一步衰減。	1 = MIN (32/2˄5， 12)

如果系統處於 CPU 壓力之下，每個查詢都會指派比其 MCE 更多的核心。如果查詢目前在其各自的 MCE 內使用所有核心，則其他查詢會等到核心可供使用。當核心可供使用時，會根據經過的行事歷時間挑選最舊的標題查詢。 MCE 是壓力上限;它不保證任何時間點的核心數目。

另請參閱

Analysis Services 中的伺服器屬性