Azure SQL Database 中的資源管理

  • 文章

適用於：Azure SQL Database

本文提供 Azure SQL Database 中資源管理的概觀。 其會提供達到資源限制時所發生情況的相關資訊，並描述用來強制執行這些限制的資源治理機制。

如需單一資料庫每個定價層的特定資源限制 (也稱為服務目標)，請參閱 DTU 型單一資料庫資源限制或 vCore 型單一資料庫資源限制。 如需彈性集區資源限制，請參閱 DTU 型彈性集區資源限制或 vCore 型彈性集區資源限制。

提示

如需 Azure Synapse Analytics 專用 SQL 集區限制，請參閱容量限制和記憶體和並行限制。

邏輯伺服器限制

資源 限制
每一邏輯伺服器的資料庫 5000
區域中每個訂用帳戶的邏輯伺服器預設數目 20
區域中每個訂用帳戶的邏輯伺服器數目上限 250
每一邏輯伺服器的 DTU/eDTU 配額 54,000
每一邏輯伺服器的 vCore 配額 540
每一邏輯伺服器的彈性集區數目上限 受限於 DTU 或 vCore 數目。 例如，如果每個集區是 1000 DTU，則伺服器可以支援 54 集區。

重要

每當資料庫數量接近每部邏輯伺服器的限制時，可能會出現下列情況：

  • 使用 master 資料庫執行查詢時，延遲狀況增加。 這包含資源使用率統計資料的檢視，例如 sys.resource_stats。
  • 管理作業以及涉及列舉伺服器中資料庫入口網站檢視點的轉譯作業，皆增加延遲狀況。

注意

若要取得更多 DTU/eDTU 配額、vCore 配額或超過預設數目的邏輯伺服器，請在 Azure 入口網站中提交新的支援要求。 如需詳細資訊，請參閱要求增加 Azure SQL Database 配額。

達到資料庫資源限制時會發生什麼情況

計算 CPU

當資料庫計算 CPU 使用率變高時，查詢延遲會增加，而且查詢甚至可能逾時。在這些情況下，查詢可能會由服務排入佇列，並在資源可用時提供資源以執行。 遇到高計算使用率時，緩和選項包括：

儲存體

當使用的資料空間達到資料庫層級或彈性集區層級的資料大小上限時，插入及更新會增加資料大小失敗，而用戶端會收到錯誤訊息。 SELECT 和 DELETE 陳述式不會受到影響。

在進階版與業務關鍵服務層級中，若單一資料庫或彈性集區的資料、交易記錄與 tempdb 所消耗的合併儲存體超過本機儲存體大小上限，則用戶端也會收到錯誤訊息。 如需詳細資訊，請參閱儲存體空間管理。

遇到高空間使用率時，緩和選項包括：

  • 增加資料庫或彈性集區的資料大小上限，或擴大至具有較高資料大小上限的服務目標。 請參閱調整單一資料庫資源和調整彈性集區資源。
  • 若資料庫在彈性集區中，則也可將其移出集區，如此便不會與其他資料庫共用其儲存空間。
  • 壓縮資料庫以回收未使用的空間。 在彈性集區中，壓縮資料庫可為集區中的其他資料庫提供更多儲存體。 如需詳細資訊，請參閱管理 Azure SQL Database 中的檔案空間。
  • 檢查高空間使用率是否肇因於持續版本存放區 (PVS) 的大小激增。 PVS 是每個資料庫的一部分，用來實作加速資料庫復原。 若要判斷目前的 PVS 大小，請參閱 PVS 疑難排解。 大型 PVS 大小的常見原因是長時間 (數小時) 開啟的交易，這會防止清除 PVS 中較舊的資料列版本。
  • 針對進階版與業務關鍵服務層級中消耗大量儲存體的資料庫與彈性集區，您可能會收到空間不足的錯誤，即使資料庫或彈性集區中的已使用空間低於其資料大小上限。 若 tempdb 或交易記錄檔消耗大量儲存體，並即將達到本機儲存體上限時，便可能發生此情況。 容錯移轉資料庫或彈性集區，以將 tempdb 重設為其較小的初始大小，或是壓縮交易記錄以減少本機儲存體耗用量。

工作階段、背景工作角色和要求

工作階段、背景工作角色和要求的定義如下：

  • 工作階段代表連線到資料庫引擎的流程。
  • 要求是查詢或批次的邏輯表示法。 要求是由連線至工作階段的用戶端所發出。 經過一段時間後，可能會在相同的工作階段上發出多個要求。
  • 背景工作執行緒 (也稱為背景工作角色或執行緒) 是作業系統執行緒的邏輯表示法。 使用平行查詢執行計畫執行時，一個要求可能具有許多背景工作角色，或使用序列 (單一執行緒) 執行計畫執行時，具有單一背景工作角色。 背景工作角色也需要支援要求以外的活動：例如，背景工作角色需要在工作階段連線時處理登入要求。

如需這些概念的詳細資訊，請參閱執行緒和工作架構指南。

工作階段與背景工作角色的數量上限取決於服務層級和計算大小。 達到工作階段或背景工作角色的限制時，會拒絕新要求，而且用戶端會收到錯誤訊息。 雖然應用程式能控制連線數目，但並行背景工作角色的數目通常難以估計及控制。 特別是在尖峰負載期間，資料庫資源達到上限，背景工作角色也由於長時間執行的查詢、大型封鎖鏈或過度的查詢平行處理原則而不斷累積。

注意

Azure SQL Database 的初始供應項目僅支援單一執行緒查詢。 在那時，要求數目一律等於背景工作角色數目。 Azure SQL Database 中的錯誤訊息 10928 包含「資料庫的要求限制為 N，且已達到其限制」的內文，以支援回溯相容性。 達到的限制實際上是背景工作角色數目。 如果平行處理原則的最大程度 (MAXDOP) 設定等於零或大於一，則背景工作角色數目可能遠高於要求數目，而且可能比 MAXDOP 等於一時更快達到限制。 深入了解資源治理錯誤中的錯誤 10928。

您可以透過下列方式緩解接近或達到背景工作角色或工作階段限制：

依服務層級和計算大小尋找 Azure SQL Database 的背景工作角色和工作階段限制：

深入了解在資源治理錯誤中針對工作階段或背景工作角色限制的特定錯誤進行疑難排解。

記憶體

不同於其他資源不同 (CPU、背景工作角色、儲存體)，達到記憶體限制並不會對查詢效能造成負面影響，也不會導致錯誤和失敗。 如記憶體管理架構指南所詳述，資料庫引擎通常會依設計使用所有可用的記憶體。 記憶體主要用於快取資料，以避免較慢的儲存體存取速度。 因此，較高的記憶體使用率通常可改善查詢效能，因為從記憶體進行較快的讀取，而不是從儲存體進行較慢的讀取。

在資料庫引擎啟動之後，當工作負載開始從儲存體讀取資料時，資料庫引擎會積極地快取記憶體中的資料。 在這個初始加速期間之後，通常預期會看到 sys.dm_db_resource_stats 中的 avg_memory_usage_percent 和 avg_instance_memory_percent 資料行接近或等於100% (特別是針對非閒置的資料庫)，而且不會完全納入記憶體中。

除了資料快取之外，還會在資料庫引擎的其他元件中使用記憶體。 當有記憶體的需求，以及資料快取已使用所有可用的記憶體時，資料庫引擎會動態減少資料快取大小，讓記憶體可供其他元件使用，並且會在其他元件釋出記憶體時動態增長資料快取。

在罕見的情況下，充分要求的工作負載可能會導致記憶體不足的狀況，進而造成記憶體不足的錯誤。 這種情況可能會發生在 0% 與 100% 之間的任何記憶體使用率層級。 這種情況更有可能發生在記憶體限制按比例較小的較小計算大小，以及 (或) 使用更多記憶體進行查詢處理的工作負載，例如在 密集彈性集區中。

遇到記憶體不足的錯誤時，緩解選項包含：

解決方法 描述
減少記憶體授與的大小 如需記憶體授與的詳細資訊，請參閱了解 SQL Server 記憶體授與部落格文章。 避免過度大量記憶體授與的常用解決方案，是將統計資料保持最新狀態。 這會讓查詢引擎更精確地估計記憶體耗用量，從而避免不必要的大量記憶體授與。

根據預設，在使用相容性層級 140 及以上的資料庫中，資料庫引擎可能會使用批次模式記憶體授與意見反應來自動調整記憶體授與大小。 同樣地，在使用相容性層級 150 及以上的資料庫中，資料庫引擎也會使用資料列模式記憶體授與意見反應，以進行更常見的資料列模式查詢。 這項內建功能可協助避免由於不必要的大量記憶體授與，而發生記憶體不足的錯誤。
減少查詢計劃快取的大小 資料庫引擎會在記憶體中快取查詢計劃，以避免在執行每個查詢時編譯查詢計劃。 若要避免只使用一次的快取計畫所造成的查詢計畫快取膨脹，請務必使用參數化查詢，並考慮啟用 OPTIMIZE_FOR_AD_HOC_WORKLOADS 資料庫範圍設定。
減少鎖定記憶體的大小 資料庫引擎會使用記憶體來進行鎖定。 可能的話，請避免可能取得大量鎖定，並導致高鎖定記憶體耗用量的大型交易。

使用者工作負載和內部流程的資源使用量

Azure SQL Database 需要計算資源來實作核心服務功能，例如高可用性和災害復原、資料庫備份和還原、監視、查詢存放區、自動調整等等。系統會使用資源管理機制，針對這些內部流程騰出整體資源的特定有限部分，讓使用者工作負載可以使用其餘的資源。 當內部流程未使用計算資源時，系統會使它們可供使用者工作負載使用。

使用者工作負載和內部流程的 CPU 和記憶體耗用量總計，會在 sys.dm_db_resource_stats 和 sys.resource_stats 檢視的 avg_instance_cpu_percent 和 avg_instance_memory_percent 資料行中報告。 對於集區層級的單一資料庫和彈性集區，也會透過 sqlserver_process_core_percent 和 sqlserver_process_memory_percent Azure 監視器計量報告此資料。

每個資料庫中使用者工作負載的 CPU 和記憶體耗用量，會在 sys.dm_db_resource_stats 和 sys.resource_stats 檢視的 avg_cpu_percent 和 avg_memory_usage_percent 資料行中報告。 對於彈性集區，sys.elastic_pool_resource_stats 檢視中會報告集區層級的資源耗用量。 對於集區層級的單一資料庫和彈性集區，也會透過 cpu_percent Azure 監視器計量報告使用者工作負載 CPU 耗用量。

使用者工作負載和內部流程最近資源耗用量的更詳細明細，會在 sys.dm_resource_governor_resource_pools_history_ex 和 sys.dm_resource_governor_workload_groups_history_ex 檢視中報告。 如需這些檢視所參考資源集區和工作負載群組的詳細資料，請參閱資源治理。 這些檢視會報告使用者工作負載的資源使用率，以及相關聯資源集區和工作負載群組中的特定內部流程。

在效能監視和疑難排解的內容中，請務必同時考慮使用者工作負載和內部流程 (avg_instance_cpu_percent、sqlserver_process_core_percent) 的使用者 CPU 耗用量 (avg_cpu_percent、cpu_percent) 和 CPU 耗用量總計。

使用者 CPU 耗用量的計算方式是以每個服務目標中的使用者工作負載限制百分比表示。 使用者 CPU 使用率 若為 100%，表示使用者工作負載已達到服務目標的限制。 不過，當CPU 耗用量總計達到 70-100% 範圍時，即使回報的使用者 CPU 耗用量仍明顯低於 100%，還是可以看到使用者工作負載輸送量持平且查詢延遲增加。 使用較小的服務目標搭配中等配置的計算資源，但相對密集的使用者工作負載 (例如在 密集彈性集區中) 時，更有可能發生這種情況。 當內部流程暫時需要額外的資源時 (例如，在建立資料庫的新複本或備份資料庫時)，較小的服務目標也會發生這種情況。

當 CPU 耗用量總計很高時，緩解選項與計算 CPU 區段中所述相同，並包含服務目標增加及/或使用者工作負載最佳化。

資源管理

為了強制執行資源限制，Azure SQL Database 會使用以 SQL Server Resource Governor 為基礎的資源治理實作，同時已將其修改並擴充至可在雲端中執行。 在 SQL Database 中，多個資源集區和工作負載群組 (同時在集區和群組層級設定資源限制) 提供平衡的資料庫即服務。 使用者工作負載和內部工作負載會分類為個別的資源集區和工作負載群組。 主要和可讀取次要複本 (包括異地複本) 上的使用者工作負載會分類為 SloSharedPool1 資源集區和 UserPrimaryGroup.DBId[N] 工作負載群組，其中 [N] 代表資料庫識別碼值。 此外，也有多個資源集區和工作負載群組適用於各種內部工作負載。

除了使用 Resource Governor 來治理資料庫引擎內的資源之外，Azure SQL Database 也會使用 Windows工作物件進行流程層級資源治理，以及使用 Windows File Server Resource Manager (FSRM) 進行儲存體配額管理。

Azure SQL Database 資源治理本質上是階層式治理。 從上到下，在作業系統層級和儲存體磁碟區層級，使用作業系統資源治理機制和 Resource Governor，接著在資源集區層級使用 Resource Governor，然後在工作負載群組層級使用 Resource Governor 來強制執行限制。 對於目前資料庫或彈性集區有效的資源治理限制，會在 sys.dm_user_db_resource_governance 檢視中報告。

資料 I/O 管理

資料 I/O 治理是 Azure SQL Database 中的流程，用來限制對資料庫資料檔案的讀取和寫入實體 I/O。 系統會針對每個服務等級設定 IOPS 限制，將「擾鄰」效果降至最低，以在多租用戶服務中提供資源配置公平性，並保持在基礎硬體和儲存體的功能內。

若為單一資料庫，工作負載群組限制會套用至針對資料庫的所有儲存體 I/O。 若為彈性集區，工作負載群組限制會套用至集區中的每個資料庫。 此外，資源集區限制會額外地套用至彈性集區的累計 I/O。 在 tempdb 中，I/O 必須遵守工作負載群組限制，但基本、標準與一般用途服務層級除外，其中套用較高的 tempdb I/O 限制。 一般而言，工作負載可能無法針對資料庫 (單一或集區) 達成資源集區限制，因為工作負載群組限制低於資源集區限制，且更快地限制 IOPS/輸送量。 不過，合併的工作負載可能會針對相同集區中的多個資料庫達到集區限制。

例如，如果查詢在沒有任何 I/O 資源管理的情況下產生 1000 IOPS，但工作負載群組的最大 IOPS 限制設定為 900 IOPS，則查詢將無法產生超過 900 的 IOPS。 不過，如果資源集區的最大 IOPS 限制設定為 1500 IOPS，且所有與資源集區相關聯的工作負載群組的 I/O 總計超過 1500 IOPS，則系統可能減少相同查詢的 I/O，以低於 900 IOPS 的工作群組限制。

sys.dm_user_db_resource_governance 檢視所傳回的 IOPS 和輸送量最大值可充當限制/上限，但不會充當保證。 此外，資源治理不保證任何特定的儲存體延遲。 給定使用者工作負載最能實現的延遲、IOPS 和輸送量，不僅取決於 I/O 資源治理限制，也取決於混合使用的 I/O 大小，以及基礎儲存體的功能。 SQL Database 會使用大小介於 512 KB 與 4 MB 之間的 I/O。 基於強制執行 IOPS 限制的目的，無論大小為何，都會計入每個 I/O，但具有 Azure 儲存體中資料檔案的資料庫除外。 在此情況下，大於 256 KB 的 IO 會以多個 256-KB I/O 計入，以與 Azure 儲存體 I/O 計入一致。

對於基本、標準和一般用途資料庫 (使用 Azure 儲存體中的資料檔案)，如果資料庫沒有足夠的資料檔案，以累計方式提供此數量的 IOPS，或如果資料未平均分散於檔案之間，或如果基礎 Blob 的效能層級限制低於資源治理限制的 IOPS/輸送量，則可能無法達到 primary_group_max_io 值。 同樣地，使用頻繁交易認可所產生的小型記錄 IO 時，由於基礎 Azure 儲存體 Blob 的 IOPS 限制，工作負載可能無法達到 primary_max_log_rate 值。 針對使用 Azure 進階儲存體的資料庫，Azure SQL Database 會使用夠大的儲存體 Blob 來取得所需的 IOPS/輸送量，不論資料庫大小為何。 針對較大的資料庫，系統會建立多個資料檔案，以增加 IOPS/輸送量容量總計。

資源使用率值 (例如在 sys.dm_db_resource_stats、sys.resource_stats 和 sys.elastic_pool_resource_stats 檢視中報告的 avg_data_io_percent 和 avg_log_write_percent)，其計算方式是以資源治理上限的百分比表示。 因此，當資源治理以外的因素限制 IOPS/輸送量時，即使回報的資源使用率仍低於100%，還是可以在工作負載增加時，看到 IOPS/輸送量持平且延遲增加。

若要判斷每個資料庫檔案的讀取和寫入 IOPS、輸送量和延遲，請使用 sys.dm_io_virtual_file_stats() 函數。 此函數會針對資料庫顯示所有 I/O (包含不計入 avg_data_io_percent 的背景 I/O)，但會使用基礎儲存體的 IOPS 和輸送量，而且可能會影響觀察到的儲存體延遲。 此函數會分別在 io_stall_queued_read_ms 和 io_stall_queued_write_ms 資料行中，報告 I/O 資源治理針對讀取和寫入所引進的額外延遲。

交易記錄速率治理

交易記錄速率治理是 Azure SQL Database 中的流程，用來限制工作負載的高內嵌速率，例如大量插入、SELECT INTO 和索引建置。 這些限制是在記錄產生速率的次秒層級進行追蹤和強制執行，而不論可以針對資料檔案發出多少 IO，都會限制輸送量。 交易記錄產生速率目前以線性方式擴大到硬體相依和服務層級相依的點。

系統會設定記錄速率，如此它們即可在各種案例中實現和維持，而整體系統可以維護其功能，並將對使用者負載的影響降到最低。 記錄速率治理可確保交易記錄備份保持在已發佈的可復原性 SLA 內。 此治理也會防止次要複本上的過度待辦項目，這可能會在容錯移轉期間導致超過預期的停機。

系統不會治理或限制交易記錄檔的實際實體 IO。 產生記錄時，會評估和評量每項作業，其是否應該延遲，以便維持所需的最大記錄速率 (MB/每秒)。 當記錄排清至儲存體時，不會增加延遲，而是在本身產生記錄速率期間套用記錄速率治理。

在執行階段所加諸的實際記錄產生速率可能也會受到回饋機制影響，這時會暫時減少允許的記錄速率，讓系統可以穩定。 記錄檔空間管理，其會避免用光記錄空間的情況，而資料複寫機制可能會暫時降低整體系統限制。

記錄速率管理員流量成形是透過下列等候類型來呈現 (在 sys.dm_exec_requests 和 sys.dm_os_wait_stats 檢視中公開)：

等候類型 備註
LOG_RATE_GOVERNOR 資料庫限制
POOL_LOG_RATE_GOVERNOR 集區限制
INSTANCE_LOG_RATE_GOVERNOR 執行個體層級限制
HADR_THROTTLE_LOG_RATE_SEND_RECV_QUEUE_SIZE 回饋控制，進階/業務關鍵中的可用性群組實體複寫未繼續進行
HADR_THROTTLE_LOG_RATE_LOG_SIZE 回饋控制，限制速率以避免記錄空間不足的狀況
HADR_THROTTLE_LOG_RATE_MISMATCHED_SLO 異地複寫回饋控制，限制記錄速率，以避免高資料延遲及避免無法使用異地次要資料庫

遇到阻礙所需可擴縮性的記錄速率限制時，請考慮下列選項：

  • 擴大至較高的服務層級，以取得服務層級的最大記錄速率，或切換至不同的服務層級。 無論選擇的服務層級為何，超大規模資料庫服務層級都會提供 100 MB/秒記錄速率。
  • 若要載入的資料為暫時性 (例如 ETL 處理序中的臨時資料)，則可將其載入至 tempdb (此為最低限度記錄)。
  • 對於分析案例、載入至叢集資料行存放區資料表，或其索引使用資料壓縮的資料表。 這會減少所需的記錄速率。 這項技術會增加 CPU 使用率，而且只適用於可從叢集資料行存放區索引或資料壓縮獲益的資料集。

儲存體空間治理

在進階和業務關鍵服務層級中，客戶資料 (包含資料檔案、交易記錄檔和 tempdb 檔案) 會儲存在機器 (其中裝載資料庫或彈性集區) 的本機 SSD 儲存體上。 本機 SSD 儲存體提供高 IOPS 和輸送量，以及低 I/O 延遲。 除了客戶資料之外，本機儲存體還會用於作業系統、管理軟體、監視資料和記錄，以及系統作業所需的其他檔案。

本機儲存體大小是有限的，而且取決於硬體功能，這會決定本機儲存體上限，或是留給客戶資料的本機儲存體。 此限制的設定旨在最大化客戶資料儲存體，同時確保安全且可靠的系統操作。 若要尋找每個服務目標的最大本機儲存體值，請參閱單一資料庫和彈性集區的資源限制文件。

您也可以使用下列查詢來尋找此值，以及給定資料庫或彈性集區目前使用的本機儲存體數量：

SELECT server_name, database_name, slo_name, user_data_directory_space_quota_mb, user_data_directory_space_usage_mb
FROM sys.dm_user_db_resource_governance
WHERE database_id = DB_ID();
資料行 描述
server_name 邏輯伺服器名稱
database_name 資料庫名稱
slo_name 服務目標名稱，包括硬體世代
user_data_directory_space_quota_mb 最大本機儲存體 (以 MB 為單位)
user_data_directory_space_usage_mb 資料檔案、交易記錄檔與 tempdb 檔案目前的本機儲存體耗用量 (MB)。 每隔 5 分鐘更新一次。

此查詢應該在使用者資料庫中執行，而不是在 master 資料庫中執行。 若為彈性集區，可以在集區中的任何資料庫中執行查詢。 報告值適用於整個集區。

重要

在進階版與業務關鍵服務層級中，若工作負載嘗試將資料檔案、交易記錄檔與 tempdb 檔案所消耗的合併本機儲存體增加超過本機儲存體上限時，便會發生空間不足的錯誤。

除了進階版與業務關鍵的 tempdb 資料庫與超大規模 RBPEX 快取以外，服務層級的資料庫也會使用本機 SSD 儲存體。 建立及刪除資料庫，以及增加或減少其大小時，機器上的本機儲存體耗用量會隨時間波動。 如果系統偵測到機器上的可用本機儲存空間很低，而且資料庫或彈性集區有用光空間的風險，則其會將資料庫或彈性集區移至具有足夠可用本機儲存體的不同機器。

此移動會以連線方式進行，類似於資料庫調整作業，而且具有類似的影響，包括在作業結束時短暫的容錯移轉 (數秒)。 此容錯移轉會終止開啟的連線並復原交易，這可能會在當時使用資料庫影響應用程式。

因為將所有資料都複製到不同機器上的本機儲存體磁碟區，所以移動進階版與業務關鍵中較大的資料庫可能需要花費大量時間。 在此期間，若資料庫、彈性集區，或 tempdb 資料庫的本機空間耗用量快速增長，則空間不足的風險也會一同增加。 系統會以平衡方式起始資料庫移動，以將空間不足的錯誤減至最少，同時避免不必要的容錯移轉。

Tempdb 大小

Azure SQL Database 中，tempdb 的大小限制取決於購買與部署模型。

若要深入了解，請檢閱下列項目的 tempdb 大小限制：

後續步驟