Azure SQL Database Hyperscale 常見問題集

超大規模資料庫是 SQL Database 中的資料庫，採用超大規模資料庫向外延展儲存體技術。 超大規模資料庫最多可支援 128 TB 的數據，並提供高輸送量和效能，以及快速調整以適應工作負載需求。 其連線、查詢處理、資料庫引擎等功能的運作方式，會與 Azure SQL 資料庫中的任何其他資料庫相同。

超大規模資料庫服務層級僅適用於 Azure SQL Database 中的單一資料庫，且採用的必須是以虛擬核心為基礎的購買模型。 在以 DTU 為基礎的購買模型中無法使用。

以虛擬核心為基礎的服務層級會根據資料庫可用性和儲存體類型、效能和最大儲存上限來區別，如下方資源限制比較所述。

超大規模資料庫服務層級適用於需要較高效能和可用性、快速備份與還原、快速儲存體以及計算可擴縮性的所有客戶。 這包括從小規模成長的客戶、執行大規模任務關鍵性資料庫的客戶、要移至雲端將其應用程式現代化的客戶，以及已在 Azure SQL 資料庫中使用其他服務層級的客戶。 使用超大規模資料庫，您將可：

• 資料庫大小可從 10 GB 成長到 128 TB。
• 從 2 個虛擬核心到 128 個虛擬核心計算虛擬核心資源
• 快速備份資料庫而無須考慮資料庫大小 (備份以儲存體快照為基礎)。
• 快速還原資料庫而無須考慮資料庫大小 (還原會從儲存體快照執行)。
• 無論資料庫大小和虛擬核心數目為何，皆有較高的記錄輸送量。
• 使用一或多個唯讀複本 (用於卸載唯讀工作負載或作為熱待命資料庫) 來讀取縮放。
• 依常數時間快速擴大計算以充分因應大量工作負載，再依常數時間縮小。 不論資料庫大小為何，調整作業對於佈建的計算需要一位數的分鐘數，而無伺服器計算則少於一秒。
• 使用無伺服器計算來為您使用的項目付費的選項，其中計算會根據使用量計費。

超大規模資料庫服務層級適用於所有可使用 Azure SQL Database 的區域。

是。 如需每部伺服器的資料庫數目限制詳細資訊，請參閱適用於伺服器上之單一和集區資料庫的 SQL Database 資源限制。

超大規模資料庫架構不僅支援大型資料庫，同時也提供高效能和高輸送量。

超大規模資料庫可根據您的工作負載需求提供快速可擴縮性。

• 相應增加/減少

  使用超大規模資料庫時，您可以在 CPU 和記憶體等資源方面相應增加主要計算大小，然後再依常數時間相應減少。 由於是遠端儲存體，因此擴大和縮小並非資料作業的大小。

  無伺服器計算的支援提供自動擴大和縮小，並根據使用量對計算進行計費。

• 相應縮小/相應放大

  透過超大規模資料庫，您可以使用三種次要複本來符合讀取縮放、高可用性和異地複寫需求。 這包括：

  • 最多四個高可用性複本，其計算大小與主要複本相同。 這些複本會作為熱待命複本，以快速地從主要複本進行容錯移轉。 您也可以使用這些複本從主要複本卸載讀取工作負載。
  • 最多 30 個具名複本，其計算大小可以與主要複本相同或不同，以符合各種讀取縮放案例。
  • 一個不同 Azure 區域的異地複本，以防範區域性中斷並啟用地理讀取縮放。

是，您可以。

否，您的應用程式開發模型會與任何其他 MSSQL 資料庫保持相同。 您應該照常使用連接字串，並使用其他一般方式與您的超大規模資料庫進行互動。 一旦您的應用程式使用超大規模資料庫，您的應用程式就能利用次要複本等功能。

在主要複本上，預設的交易隔離等級是 RCSI (讀取認可快照隔離)。 在讀取縮放次要複本上，預設隔離等級為快照集。 這與任何其他 Azure SQL 資料庫均相同。

2023 年 12 月15 日起，新建立的超大規模資料庫、所有無伺服器超大規模資料庫和所有超大規模資料庫彈性集區的計算價格已降低。 有了新的簡化定價，不需要套用 Azure Hybrid Benefit (AHB) 即可節省相同的成本。 Azure Hybrid Benefit (AHB) 只能套用至佈建計算的舊版 (2023 年 12 月 15 日之前建立) 超大規模資料庫單一資料庫。 若為舊版資料庫，AHB 僅適用至 2026 年 12 月為止，此後這些資料庫也會根據新的簡易定價計費。 如需詳細資訊，請參閱超大規模資料庫定價部落格和 Azure SQL 資料庫超大規模資料庫 – 較低的簡易定價！。

超大規模資料庫適用於所有工作負載類型，包括 OLTP、混合式 (HTAP) 及分析 (資料超市) 工作負載。

如果您目前使用 SQL Server 作為數據倉儲來執行互動式分析查詢，超大規模資料庫是一個很好的選項，因為您可以以較低的成本裝載小型和中型數據倉儲（例如數 TB 高達 128 TB），而且您可以以最少的 T-SQL 程式代碼變更將 SQL Server 數據倉儲工作負載遷移至超大規模資料庫。

如果您要大規模執行數據分析，且查詢複雜且持續擷取速率高於 100 MB/秒，或使用平行數據倉儲 （PDW）、Teradata 或其他大規模平行處理 （MPP） 數據倉儲，例如 Azure Synapse Analytics，則Microsoft Fabric 可能是最佳選擇。

擷取或記錄產生速率為 150 MB/秒，可作為加入預覽功能。 如需詳細資訊，以及選擇加入150 MB/秒，請參閱 部落格：2024年11月超大規模資料庫增強功能。

目前沒有。 不過，您可以調整計算和複本數目，以降低非尖峰時間的成本，或使用無伺服器，以根據使用量來自動調整計算。

針對讀取工作負載，您可以建立具有比主要複本更高計算大小 (更多核心和記憶體) 的具名複本。 如需可用計算大小的詳細資訊，請參閱超大規模資料庫儲存體和計算大小。

針對讀取工作負載，這可以使用具名複本來達成。

您可以使用 Azure 入口網站或 REST API，調整 0 和 4 之間的高可用性次要複本數目。 此外，您可以針對許多讀取縮放案例，建立最多 30 個具名複本。

在超大規模資料庫中，儲存體層級會提供資料復原。 您只需要一個複本 (主要複本) 即可提供復原。 計算複本失效時，將會自動建立新複本，且不會遺失資料。

不過，如果只有主要複本，可能需要一到兩分鐘的時間才能在容錯移轉之後建立新的複本；相較之下，當高可用性次要複本可供使用時，則只需要幾秒鐘的時間。 新的複本一開始會有冷快取，這可能會導致儲存體延遲較高，並在容錯移轉之後立即降低查詢效能。

針對需要高可用性且容錯移轉影響最低的任務關鍵性應用程式，您至少應該佈建一個高可用性次要複本，以確保可以使用熱待命複本做為容錯移轉目標。

單一超大規模資料庫的大小上限目前為 128 TB。 超大規模資料庫彈性集區中資料庫的大小上限目前為 100 TB。

在超大規模資料庫中，交易記錄大小幾乎是無限的，但記錄的使用中部分超出 1 TB。 記錄的作用中部分可能會因為長時間執行的交易，或因為異動資料擷取處理而成長，而無法跟上資料變更的速率。 避免不必要的長時間大型交易，以維持在此限制以下。 除了此限制以外，您無須擔心記錄輸送量高的系統是否會有記錄空間不足的問題。 不過，對於持續積極寫入的工作負載，記錄產生速率可能會受到節流控制。 尖峰持續的記錄產生速率是 100 MB/秒。

記錄產生速率為 150 MB/秒，可作為選擇加入預覽功能。 如需詳細資訊，以及選擇加入150 MB/秒，請參閱 部落格：2024年11月超大規模資料庫增強功能。

您的 tempdb 資料庫位於本機 SSD 儲存體，其大小與您佈建的計算大小 (核心數) 成正比。 tempdb 大小無法設定，並且會為您管理。 若要為資料庫判斷 tempdb 大小上限，請參閱超大規模資料庫儲存體和計算大小。

您的資料庫大小會在您插入/擷取更多資料時自動成長。

10 GB。 建立的超大規模資料庫的起始大小為 10 GB，並視需要以 10 GB 區塊成長。

每個資料檔案每次會成長 10 GB。 多個資料檔案可能會同時成長。

在「超大規模資料庫」中，資料檔案會儲存在 Azure 標準儲存體中。 資料會在計算複本遠端頁面伺服器的本機 SSD 儲存體上進行完整快取。 此外，計算複本在本機 SSD 和記憶體中都有資料快取，以降低從遠端頁面伺服器中提取資料的頻率。

不會。 資料檔案會自動新增至 PRIMARY 檔案群組。 建立其他檔案群組的常見原因不適用於超大規模資料庫儲存體結構，或更廣泛的 Azure SQL Database。

不可以。

是，資料庫和檔案壓縮作業目前為預覽狀態。 如需有關預覽狀態的詳細資訊，請參閱 Azure SQL 超大規模資料庫的壓縮。

是，就像在任何其他 Azure SQL DB 資料庫中一樣。 這包括資料列、頁面和資料行存放區壓縮。

可以。 與指定的資料表相關聯的資料頁面可能會移至多個資料檔案中，但全都屬於相同的檔案群組。 MSSQL 資料庫引擎會使用按比例填滿策略，將資料分散到多個資料檔案。

可以。 您可以將 Azure SQL Database 中的現有資料庫移至超大規模資料庫。 建議您建立一份資料庫副本，並將副本遷移至超大規模資料庫以進行概念證明 (POC)。

將現有資料庫移至超大規模資料庫所需的時間包含複製資料的時間，以及在複製資料時重新執行來源資料庫所做變更的時間。 資料複製時間與資料大小成正比。 如果在寫入活動低的期間移動，則重新執行變更的時間比較短。

取得範例程式碼，使用 Azure 入口網站、Azure CLI、PowerShell 和 Transact-SQL 將現有的 Azure SQL Databases 移轉到超大規模資料庫，如將現有的資料庫移轉到超大規模資料庫中所述。

如果超大規模資料庫不符合其需求，反向移轉到一般用途服務層級可讓最近將 Azure SQL Database 中現有資料庫移轉到超大規模資料庫服務層級的客戶能夠移轉回來。 雖然反向移轉是由服務層級變更所起始，但其基本上是不同結構之間的資料大小作業。 類似於移轉到超大規模資料庫，反向移轉在低寫入活動期間會更快完成。 了解反向移轉的限制。

如果您先前已將現有的 Azure SQL Database 移轉到超大規模資料庫服務層級，您可以在超大規模資料庫原始移轉的 45 天內，將其反向移轉到一般用途服務層級。 如果您想要將資料庫移轉到另一個服務層級 (例如業務關鍵)，請先反向移轉到一般用途服務層級，再修改服務層級。 反向移轉是資料大小作業。

在超大規模資料庫服務層級建立的資料庫，無法移至其他服務層級。

了解如何從超大規模資料庫反向移轉，包括反向移轉的限制和受影響的備份原則。

可以。 超大規模資料庫尚不支援某些 Azure SQL Database 功能。 如果已為您的資料庫啟用其中一些功能，可能會無法移轉到超大規模資料庫，或者這些功能會在移轉後停止運作。 我們預期這些限制是暫時性的。 如需詳細資料，請參閱已知限制。

可以。 您可以使用許多現有的移轉技術來移轉到超大規模資料庫，包括異動複寫，以及任何其他資料移動技術 (大量複製、Azure Data Factory、Azure Databricks、SSIS)。 另請參閱 Azure 資料庫移轉服務，其支援許多移轉案例。

移轉至超大規模資料庫的停機時間與您將資料庫遷移至其他 Azure SQL Database 服務層級的停機時間相同。 移轉大小未超過數 TB 的資料庫時，您可以使用異動複寫盡可能縮短停機時間。 針對非常大型的資料庫 (10+ TB)，您可以考慮使用 ADF、Spark 或其他大量資料移動技術來實作移轉程序。

超大規模資料庫能夠以 100 MB/秒的速率取用新/變更資料，但將資料移至 Azure SQL Database 中的資料庫的所需時間也會受到可用網路輸送量、來源讀取速度和目標資料庫服務層級目標的影響。 記錄產生速率為 150 MB/秒，可作為選擇加入預覽功能。 如需詳細資訊，以及選擇加入150 MB/秒，請參閱 部落格：2024年11月超大規模資料庫增強功能。

您可以讓用戶端應用程式從 Azure 儲存體讀取資料，並將資料載入超大規模資料庫 (就像您可以在 Azure SQL Database 中的任何其他資料庫一樣)。 Azure SQL Database 目前不支援 Polybase。 做為提供快速載入的替代方案，您可以使用 Azure Data Factory，或透過適用於 SQL 的 Spark 連接器，在 Azure Databricks 中使用 Spark 作業。 SQL 的 Spark 連接器支援大量插入。

您也可以使用 BULK INSERT 或 OPENROWSET，從 Azure Blob 存放區大量讀取資料：大量存取 Azure Blob 儲存體中資料的範例。

「超大規模資料庫」不支援簡單復原或大量記錄模式。 若要提供高可用性和時間點復原，必須使用完整復原模式。 不過，相較於其他 Azure SQL Database 服務層級，超大規模資料庫記錄架構提供更佳的資料內嵌速度。

否。 超大規模資料庫是對稱式多處理 (SMP) 結構，而不是大量平行處理 (MPP) 或多重主機結構。 您只能建立多個複本以相應放大唯讀工作負載。

可以。 Azure 資料庫移轉服務支援許多移轉案例。

請參閱 Azure SQL Database 的 SLA。 建議您為關鍵工作負載新增高可用性次要複本。 這可加快容錯移轉速度，並在容錯移轉後立即降低潛在效能影響。

是。

是，超大規模資料庫支援區域備援設定。 至少需要一個高可用性次要複本，以及使用區域備援或異地區域備援儲存體，才能啟用超大規模資料庫的區域備援設定。

是。 如需詳細資訊，請參閱超大規模資料庫彈性集區和部落格︰超大規模資料庫彈性集區現時正式發行。

超大規模資料庫並沒有傳統的完整、差異和交易記錄備份。 相反地，資料檔案有一般儲存體快照集，每個檔案都有個別的快照頻率。 在設定保留期間內，所產生的交易記錄會依原樣保留。 還原時，會將相關的交易記錄套用至已還原的儲存體快照集。 不論快照頻率為何，這都會產生截至保留期間內的指定時間點未遺失任何資料的交易一致性資料庫。 實際上，超大規模資料庫中的資料庫備份是持續進行的。

是。

時間點還原的復原點目標 (RPO) 為 0 分鐘。 大部分的時間點還原作業會在 60 分鐘內完成，不論資料庫大小為何。 對於較大的資料庫，而且如果資料庫在還原時間點之前有大量的寫入活動，還原時間可能會更長。 發出還原時變更儲存體備援可能會導致還原時間增長，因為還原涉及資料大小，因此時間將會與資料庫大小成正比。

否。 備份由儲存子系統管理，並使用儲存體快照。 它們不會影響使用者工作負載。

是。 如果使用異地備援儲存體，則完全支援異地還原。 這是新資料庫的預設值。 不同於時間點還原，異地還原需要資料大小作業。 資料檔案會以平行方式複製，因此，此作業的持續時間主要取決於資料庫中最大檔案的大小，而不是資料庫大小總計。 如果在與來源資料庫區域配對的 Azure 區域中還原資料庫，異地複寫時間將會大幅縮短。

可以。 您可以針對超大規模資料庫設定異地複寫。

不會。 超大規模資料庫的儲存格式與任何發行版本的 SQL Server 不同，而且您無法控制備份或加以存取。 若要將您的資料移出超大規模資料庫，您可以使用任何資料移動技術 (亦即 Azure Data Factory、Azure Databricks、SSIS 等) 來擷取資料。

是。 自 2022 年 5 月 4 日起，所有新資料庫的備份會依照 Azure SQL 資料庫定價頁面中擷取的費率，根據使用的備份儲存體和選取的儲存體備援來收費。 針對在 2022 年 5 月 4 日以前建立的超大規模資料庫，只有在備份保留期設定為大於七天時，才會收取備份費用。 若要深入了解，請參閱超大規模資料庫備份和儲存體備援。

如需如何測量備份儲存體大小的詳細資料，請參閱自動備份。

若要判斷您的備份儲存體帳單，請定期計算備份儲存大小，並乘以備份儲存體費率和上次計算後的時數。 若要預估一段時間的備份帳單，請將期間每小時的可計費備份儲存體大小乘以備份儲存體費率，然後加總所有每小時金額。 若要以程式設計方式查詢多個每小時間隔的相關 Azure 監視器計量，請使用 Azure 監視器 REST API。 無伺服器計算層中的備份計費與已佈建的計算層相同。

針對在資料庫中新增、修改或刪除大量資料的工作負載，備份成本會較高。 相反地，大部分為唯讀的工作負載可能會有較小的備份成本。

如需如何將備份儲存體成本降到最低的詳細資料，請參閱自動備份。

目前，非超大規模資料庫服務層級（標準/進階/一般用途/業務關鍵）備份無法異地還原到超大規模資料庫服務層級，反之亦然。 若要將非超大規模資料庫轉換成超大規模資料庫，請在還原之後變更服務層級。

針對任何超大規模資料庫計算大小，交易記錄輸送量上限設為 100 MB/秒。 達到此速率的能力取決於多個因素，包括但不限於工作負載類型、用戶端設定和效能，以及在主要計算複本上具有足夠的計算容量，以此速率產生記錄。 記錄產生速率為 150 MB/秒，可作為選擇加入預覽功能。 如需詳細資訊，以及選擇加入150 MB/秒，請參閱 部落格：2024年11月超大規模資料庫增強功能。

IOPS 和 IO 延遲會根據工作負載模式而有所不同。 如果要存取的資料快取在計算複本的 RBPEX 中，您會看到類似於業務關鍵或進階服務層級的 IO 效能。

不可以。 計算會與儲存層分離。 這可消除備份的效能影響。

由於儲存體是共用的，且主要與次要計算複本之間並不會執行直接的實體複寫，主要複本上的輸送量將不會因為新增次要複本而受到直接影響。 不過，持續且積極的寫入工作負載會在主要複本上進行節流控制，讓次要複本上的記錄套用和頁面伺服器能夠趕上進度。 這可避免次要複本上的讀取效能不佳，以及在容錯移轉到高可用性次要複本之後的復原時間很長。

是。 不過，就像在其他 Azure SQL DB 資料庫中一樣，連線可能會因為非常罕見的暫時性錯誤而終止，而可能會中止長時間執行的查詢和復原交易。 暫時性錯誤的其中一個原因是，系統快速將資料庫移至不同的計算節點，以確保持續進行計算和儲存體資源可用性，或為了執行計畫性維護。 其中大部分重新設定事件會在不到 10 秒內完成。 連接到您資料庫的應用程式需藉由執行重試邏輯，來預料並容忍這些不常發生的暫時性錯誤的發生。 此外，請考慮設定符合您工作負載排程的 維護時間範圍，以避免因計畫性維護而造成暫時性錯誤。

針對大部分的效能問題，特別是非根源於儲存體效能的問題，會套用常見的 SQL 診斷和疑難排解步驟。 如需超大規模資料庫特定的儲存體診斷，請參閱 SQL 超大規模資料庫效能疑難排解診斷。

無伺服器資料庫可擴大的最大記憶體數量是 3 GB/虛擬核心數乘上所設定虛擬核心數上限，相較於超過 5 GB/虛擬核心數乘上已佈建計算中的相同虛擬核心數。 如需詳細資料，請檢閱無伺服器超大規模資料庫資源限制。

不論資料大小為何，已佈建計算層中的擴大或縮小通常最多需要 2 分鐘的時間。 在根據工作負載需求自動調整計算的無伺服器計算層級中，調整時間通常為亞秒，但有時可能需要調整已佈建計算的時間。

否。 資料庫會在相應擴大或相應縮小作業期間維持在線上狀態。

如果在調整作業最後發生容錯移轉，則擴大或縮小已佈建的計算會導致連線中斷。 在無伺服器計算中，自動調整通常不會產生連線中斷，但偶而會發生。 新增或移除次要複本並不會導致主要複本的連線中斷。

已佈建計算中的調整是由終端使用者所執行。 無伺服器計算中的自動調整是由服務所執行。

可以。 計算節點上的 tempdb 資料庫和 RBPEX 快取大小會隨著核心數目的增加而自動相應增加。 如需詳細資料，請參閱超大規模資料庫儲存體和計算大小。

否。 只有主要計算複本會接受讀取/寫入要求。 次要計算複本僅接受唯讀要求。

超大規模資料庫支援高可用性 (HA) 複本、具名複本和異地複寫複本。 如需詳細資料，請參閱超大規模資料庫次要複本。

介於 0 到 4。 如果您想要調整複本數目，可以使用 Azure 入口網站 或 REST API。

您可以藉由將連接字串中的 ApplicationIntent 屬性設定為 ReadOnly 來連線到這些額外的唯讀計算複本。 任何標示為 ReadOnly 的連線都會自動路由到其中一個高可用性次要複本 (如果存在)。 如需詳細資料，請參閱使用唯讀複本對唯讀查詢工作負載進行卸載。

您可以執行下列 T-SQL 查詢：SELECT DATABASEPROPERTYEX ('<database_name>', 'Updateability')。 如果連線到唯讀次要複本，結果為 READ_ONLY，如果連線至主要複本，則結果為 READ_WRITE。 資料庫內容必須設定為您的資料庫名稱，而不是設定為 master 資料庫。

否。 您只能藉由指定 ApplicationIntent=ReadOnly 來連線到高可用性次要複本。 不過，您可以為具名複本建立專用端點。

不會。 具有唯讀意圖的新連線會重新導向至任意的高可用性次要複本。

不在已佈建的計算層中。 高可用性次要複本會作為高可用性容錯移轉目標，因此必須與主要複本具有相同的設定，才能在容錯移轉後提供預期的效能。 在無伺服器中，會根據每個高可用性複本的個別工作負載需求來自動調整其計算。 每個高可用性次要複本仍然可以自動調整為已設定的最大核心數，以容納其容錯移轉後角色。 具名複本 提供個別調整每個複本的能力。

否。 您的 tempdb 資料庫是根據已佈建計算大小來設定的；而您的高可用性次要複本的大小也是相同的，包括以 tempdb 作為主要計算。 在具名複本上，tempdb 的大小會根據複本的計算大小調整，因此它可以小於或大於主資料庫上 tempdb 的大小。

否。 超大規模資料庫會計算複本共用儲存體，這表示所有計算複本都會看到相同的資料表、索引及其他資料庫物件。 如果希望為次要複本的讀取最佳化額外索引，您必須在主要複本上新增這些索引。 您仍然可以在每個次要複本上建立暫存資料庫 (資料表名稱前面加上 # 或 # #)，以儲存暫存資料。 暫存資料表為可讀寫。

從交易在主要資料庫上認可，到可在次要資料庫上讀取的這段時間，資料延遲的狀況取決於目前的記錄產生速率、交易大小、複本的負載以及其他因素。 小型交易的一般資料延遲時間為數十毫秒，不過資料延遲時間沒有上限。 指定次要複本上的資料一律是交易一致的，因此較大的交易需要較長的時間才能傳播。 不過，在指定的時間點，不同次要複本的資料延遲和資料庫狀態可能會不同。 需要立即讀取認可資料的工作負載應該在主要複本上執行。

否，具名複本無法用作主要複本的容錯移轉目標。 針對該用途請新增 HA 複本。

每個具名複本可能都有不同的服務等級目標，因此用於不同的使用案例，所以沒有內建方法可將傳送至主要複本的唯讀流量導向至一組具名複本。 例如，您有八個具名複本，但您只想將 OLTP 工作負載導向至具名複本 1 至 4，而 Power BI 分析工作負載會使用具名複本 5 和 6，資料科學工作負載則使用複本 7 和 8。 視所使用的工具或程式設計語言而定，散發這類工作負載的策略可能有所不同。 如需建立工作負載路由解決方案，以允許 REST 後端擴增的範例，請檢閱 OLTP 擴增範例。

不行，因為具名複本和主要複本使用相同的頁面伺服器，所以必須位於同一區域。

具名複本不會影響主要複本的可用性。 在正常情況下，具名複本不太可能會影響主要複本的效能，但如果有大量工作負載正在執行，就可能會發生這種情況。 如同 HA 複本，具名複本會透過交易記錄服務，和主要複本保持同步。 如果具名複本基於任何原因而導致取用交易記錄的速度不構塊，就會開始要求主要複本降低記錄產生速度 (節流)，以便其能趕上。 雖然此行為不會影響主要複本的可用性，但會影響主要複本寫入工作負載的效能。 為避免這種情況，請確定具名複本有足夠的資源空餘空間 (主要是 CPU)，以便在不延遲的情況下處理交易記錄。 例如，如果主要複本正在處理許多資料變更，建議至少讓具名複本具備和主要複本相同的服務等級目標，以免造成複本的 CPU 飽和，進而強制主要複本降低速度。

具名複本仍如常提供唯讀存取。

根據預設，具名複本沒有任何自己的高可用性複本。 具名複本的容錯移轉需要先建立新的複本，這通常需要約 1-2 分鐘的時間。 不過，具名複本也可以因高可用性複本所帶來的更高可用性和較短容錯移轉時間而獲益。 若要為具名複本新增高可用性複本，您可以透過 AZ CLI 使用參數 ha-replicas，或透過 PowerShell 使用參數 HighAvailabilityReplicaCount，或透過 REST API 使用 highAvailabilityReplicaCount 屬性。 您可以在建立具名複本期間設定高可用性複本的數目，且命名複本在建立後可隨時變更 (僅能透過 AZ CLI、PowerShell 或 REST API)。 具名複本的高可用性複本其定價和一般超大規模資料庫的高可用性複本定價相同。

是。 資料行主要金鑰儲存於使用者資料庫，而且執行查詢 SELECT * FROM sys.column_master_keys 即可驗證。 具名複本和高可用性次要複本會從與主要超大規模資料庫相同的頁面伺服器/儲存層讀取資料。 這兩種類型的複本都會透過記錄服務與主要超大規模資料庫同步處理。 金鑰變更視同交易，而且會自動複寫至具名複本和高可用性次要複本。

函式 DATABASEPROPERTYEX() 在具名複本的內容內執行時，可以將 replica_id 對應至相應的具名複本。 不過，從主要複本查詢時，目前無法針對 sys.dm_database_replica_states 動態管理檢視中的每項記錄，將 replica_id 連結到各自的具名複本。 下列範例查詢可以在具名複本的內容執行，以識別複本名稱、複本識別碼和同步處理詳細資料。

  SELECT replica_id, DB_NAME() AS 'Database/Replica name', 
  synchronization_state_desc, log_send_queue_size/1024.0/1024.0 AS log_send_queue_size_gb,
  last_sent_time, last_received_time, last_commit_time, secondary_lag_seconds
  FROM sys.dm_database_replica_states
  WHERE replica_id = DATABASEPROPERTYEX(DB_NAME(),'REPLICAID');

相關內容

如需超大規模資料庫服務層級的詳細資訊，請參閱超大規模資料庫服務層級。