彈性集區可協助您管理及調整 Azure SQL Database 中的多個資料庫Elastic pools help you manage and scale multiple databases in Azure SQL Database

適用於: Azure SQL Database

Azure SQL Database 彈性集區是一種簡單、符合成本效益的解決方案,可用於管理及調整具有不同且無法預測之使用需求的多個資料庫。Azure SQL Database elastic pools are a simple, cost-effective solution for managing and scaling multiple databases that have varying and unpredictable usage demands. 彈性集區中的資料庫位於單一伺服器上,並以設定的價格共用設定的資源數量。The databases in an elastic pool are on a single server and share a set number of resources at a set price. Azure SQL Database 中的彈性集區可讓 SaaS 開發人員將一組資料庫的價格效能最佳化在規定的預算內,同時為每個資料庫提供效能彈性。Elastic pools in Azure SQL Database enable SaaS developers to optimize the price performance for a group of databases within a prescribed budget while delivering performance elasticity for each database.

SQL 彈性集區是什麼What are SQL elastic pools

SaaS 開發人員會在由多個資料庫組成的大規模資料層上建置應用程式。SaaS developers build applications on top of large scale data-tiers consisting of multiple databases. 常見的應用程式模式是為每個客戶佈建單一資料庫。A common application pattern is to provision a single database for each customer. 但是不同的客戶通常會有不同且無法預測的使用模式,而且很難預測每個個別資料庫使用者的資源需求。But different customers often have varying and unpredictable usage patterns, and it's difficult to predict the resource requirements of each individual database user. 您通常有兩個選項:Traditionally, you had two options:

  • 根據尖峰使用量額外佈建資源並額外付款,或是Over-provision resources based on peak usage and over pay, or
  • 少量佈建來節省成本,但會降低尖峰期間的效能和客戶滿意度。Under-provision to save cost, at the expense of performance and customer satisfaction during peaks.

彈性集區可藉由確保資料庫會在需要時取得它們所需的效能資源,來解決此問題。Elastic pools solve this problem by ensuring that databases get the performance resources they need when they need it. 它們會在可預測的預算內提供簡單的資源配置機制。They provide a simple resource allocation mechanism within a predictable budget. 若要深入了解使用彈性集區的 SaaS 應用程式的設計模式,請參閱 採用 Azure SQL Database 的多租用戶 SaaS 應用程式的設計模式To learn more about design patterns for SaaS applications using elastic pools, see Design Patterns for Multi-tenant SaaS Applications with Azure SQL Database.


彈性集區沒有每一資料庫的費用。There is no per-database charge for elastic pools. 對於集區存在的每個小時,您均需要支付最高的 eDTU 或 vCore,不論使用量多高,或使用集區的時間是否少於一小時。You are billed for each hour a pool exists at the highest eDTU or vCores, regardless of usage or whether the pool was active for less than an hour.

彈性集區可讓開發人員為由多個資料庫共用的集區購買資源,以容納個別資料庫無法預期的使用量期間。Elastic pools enable the developer to purchase resources for a pool shared by multiple databases to accommodate unpredictable periods of usage by individual databases. 您可以根據以 DTU 為基礎的購買模型以虛擬核心為基礎的購買模型,為集區設定資源。You can configure resources for the pool based either on the DTU-based purchasing model or the vCore-based purchasing model. 集區的資源需求取決於其資料庫的彙總使用量。The resource requirement for a pool is determined by the aggregate utilization of its databases. 集區可用的資源數量是由開發人員預算控制。The amount of resources available to the pool is controlled by the developer budget. 開發人員只需將資料庫新增至集區,並選擇性地設定資料庫的最小和最大資源 (最小值和最大 Dtu 數或最小值或最大值虛擬核心,視您選擇的資源模型) 而定,然後根據其預算設定集區的資源。The developer simply adds databases to the pool, optionally sets the minimum and maximum resources for the databases (either minimum and maximum DTUs or minimum or maximum vCores depending on your choice of resourcing model), and then sets the resources of the pool based on their budget. 開發人員可以使用集區順暢地擴大其服務,以漸增的規模從精簡的新創公司到成熟的企業。A developer can use pools to seamlessly grow their service from a lean startup to a mature business at ever-increasing scale.

在集區內,會給予個別資料庫彈性以在設定的參數內自動調整。Within the pool, individual databases are given the flexibility to auto-scale within set parameters. 負載量大時,資料庫可以取用更多的資源以滿足需求。Under heavy load, a database can consume more resources to meet demand. 負載較輕的資料庫取用較少的資源,而完全無負載的資料庫不會取用任何資源。Databases under light loads consume less, and databases under no load consume no resources. 針對整個集區佈建資源,而不是針對單一資料庫佈建資源,可簡化管理工作。Provisioning resources for the entire pool rather than for single databases simplifies your management tasks. 此外,您還可以有可預測的集區預算。Plus, you have a predictable budget for the pool. 您可以將其他資源新增至具有最短停機時間的現有集區。Additional resources can be added to an existing pool with minimum downtime. 同樣地,如果不再需要額外資源,則隨時可以從現有集區中移除。Similarly, if extra resources are no longer needed they can be removed from an existing pool at any point in time. 您可以從集區新增或移除資料庫。And you can add or remove databases from the pool. 如果可以預測資料庫使用少量資源,則將它移出。If a database is predictably under-utilizing resources, move it out.


將資料庫移入或移出彈性集區時,除了資料庫連線中斷時作業結尾的一小段時間之外 (大約數秒),不會有停機時間。When moving databases into or out of an elastic pool, there is no downtime except for a brief period of time (on the order of seconds) at the end of the operation when database connections are dropped.

何時該考慮使用 SQL Database 彈性集區When should you consider a SQL Database elastic pool

集區非常適合大量具有特定使用模式的資料庫。Pools are well suited for a large number of databases with specific utilization patterns. 針對指定的資料庫,此模式的特徵是低平均使用量與相對不頻繁的使用量高峰。For a given database, this pattern is characterized by low average utilization with relatively infrequent utilization spikes. 相反地,具有持續性中等高使用率的多個資料庫不應放置在相同的彈性集區中。Conversely, multiple databases with persistent medium-high utilization should not be placed in the same elastic pool.

您可以加入集區的資料庫愈多,可獲得的節約就愈高。The more databases you can add to a pool the greater your savings become. 視您的應用程式使用量模式而定,您可以使用兩個 S3 資料庫來查看節省的成本。Depending on your application utilization pattern, it's possible to see savings with as few as two S3 databases.

下列各節會協助您了解如何評估您特定的資料庫集合是否可以因為位於集區而受益。The following sections help you understand how to assess if your specific collection of databases can benefit from being in a pool. 範例會使用標準集區,但是相同的原則也適用於基本和進階的集區。The examples use Standard pools but the same principles also apply to Basic and Premium pools.

評估資料庫使用量模式Assessing database utilization patterns

下圖顯示資料庫的範例,該資料庫花費太多時間閒置,但也定期因活動達到尖峰。The following figure shows an example of a database that spends much time idle, but also periodically spikes with activity. 這是適合集區的使用量模式:This is a utilization pattern that is suited for a pool:


此圖表說明從12:00 到1:00 的1小時時間內的 DTU 使用量,其中每個資料點都有1分鐘的資料細微性。The chart illustrates DTU usage over a 1 hour time period from 12:00 to 1:00 where each data point has 1 minute granularity. 在 12:10 DB1 尖峰高達 90 Dtu,但其整體平均使用量低於五個 Dtu。At 12:10 DB1 peaks up to 90 DTUs, but its overall average usage is less than five DTUs. 需要 S3 計算大小,才能在單一資料庫中執行此工作負載,但這會在活動較少的期間保留大多數的資源未使用。An S3 compute size is required to run this workload in a single database, but this leaves most of the resources unused during periods of low activity.

集區可讓這些未使用的 DTU 跨多個資料庫共用,並因此減少需要的 DTU 和整體成本。A pool allows these unused DTUs to be shared across multiple databases, and so reduces the DTUs needed and overall cost.

以上一個範例為建置基礎,假設有其他資料庫具有與 DB1 類似的使用量模式。Building on the previous example, suppose there are additional databases with similar utilization patterns as DB1. 在接下來的兩個圖形中,4 個資料庫和 20 個資料庫的使用量分層放在相同的圖形,說明使用以 DTU 為基礎的購買模型經過一段時間其使用量非重疊的本質:In the next two figures below, the utilization of four databases and 20 databases are layered onto the same graph to illustrate the non-overlapping nature of their utilization over time using the DTU-based purchasing model:

使用量模式適合某個集區的 4 個資料庫

使用量模式適合某個集區的 20 個資料庫

在上圖中,黑色線條說明跨所有 20 個資料庫的彙總 DTU 使用量。The aggregate DTU utilization across all 20 databases is illustrated by the black line in the preceding figure. 這顯示彙總的 DTU 使用量永遠不會超過 100 個 DTU,並指出 20 個資料庫可以在這段期間共用 100 個 eDTU。This shows that the aggregate DTU utilization never exceeds 100 DTUs, and indicates that the 20 databases can share 100 eDTUs over this time period. 相較於將每個資料庫放在單一資料庫的 S3 計算大小,這會導致 DTU 減少 20 倍且價格降低 13 倍。This results in a 20x reduction in DTUs and a 13x price reduction compared to placing each of the databases in S3 compute sizes for single databases.

由於以下原因,此範例很理想:This example is ideal for the following reasons:

  • 每一資料庫之間的尖峰使用量和平均使用量有相當大的差異。There are large differences between peak utilization and average utilization per database.
  • 每個資料庫的尖峰使用量會在不同時間點發生。The peak utilization for each database occurs at different points in time.
  • eDTU 會在許多資料庫之間共用。eDTUs are shared between many databases.

集區的價格是集區 eDTU 的函式。The price of a pool is a function of the pool eDTUs. 雖然集區的 eDTU 單價較單一資料庫的 DTU 單價高 1.5 倍,但是集區 eDTU 可由多個資料庫共用,而需要的 eDTU 總數會比較少While the eDTU unit price for a pool is 1.5x greater than the DTU unit price for a single database, pool eDTUs can be shared by many databases and fewer total eDTUs are needed. 價格方面和 eDTU 共用的這些差異是集區可以提供價格節約潛力的基礎。These distinctions in pricing and eDTU sharing are the basis of the price savings potential that pools can provide.

下列資料庫計數和資料庫使用量相關規則的經驗法則,可協助確保集區可提供相較於使用單一資料庫的計算大小降低的成本。The following rules of thumb related to database count and database utilization help to ensure that a pool delivers reduced cost compared to using compute sizes for single databases.

資料庫的最小數目Minimum number of databases

如果單一資料庫的資源彙總數量大於集區所需資源的 1.5 倍,則彈性集區會更符合成本效益。If the aggregate amount of resources for single databases is more than 1.5x the resources needed for the pool, then an elastic pool is more cost effective.

DTU 為基礎的購買模型範例100 eDTU 集區至少需要兩個 S3 資料庫或至少15個 S0 資料庫,才能比使用單一資料庫的計算大小更符合成本效益。DTU-based purchasing model example At least two S3 databases or at least 15 S0 databases are needed for a 100 eDTU pool to be more cost-effective than using compute sizes for single databases.

並行尖峰資料庫的最大數目Maximum number of concurrently peaking databases

藉由共用資源,並非集區中的所有資料庫都能同時使用資源達到單一資料庫的最大限制。By sharing resources, not all databases in a pool can simultaneously use resources up to the limit available for single databases. 同時尖峰的資料庫愈少,可以設定的集區資源愈低,集區就能更符合成本效益。The fewer databases that concurrently peak, the lower the pool resources can be set and the more cost-effective the pool becomes. 一般而言,集區中應該不能有超過 2/3 (或 67%) 的資料庫同時達到其資源限制的尖峰。In general, not more than 2/3 (or 67%) of the databases in the pool should simultaneously peak to their resources limit.

DTU 為基礎的購買模型範例為了降低 200 eDTU 集區中三個 S3 資料庫的成本,這些資料庫中最多有兩個都可以同時尖峰其使用率。DTU-based purchasing model example To reduce costs for three S3 databases in a 200 eDTU pool, at most two of these databases can simultaneously peak in their utilization. 否則,如果 4 個 S3 資料庫中超過 2 個同時尖峰,則必須將集區調整為超過 200 個 eDTU。Otherwise, if more than two of these four S3 databases simultaneously peak, the pool would have to be sized to more than 200 eDTUs. 如果將集區調整大小為超過 200 個 eDTU,則需要加入更多的 S3 資料庫至集區,以使成本保持低於單一資料庫的計算大小。If the pool is resized to more than 200 eDTUs, more S3 databases would need to be added to the pool to keep costs lower than compute sizes for single databases.

請注意,此範例不考慮集區中其他資料庫的使用率。Note this example doesn't consider utilization of other databases in the pool. 如果所有資料庫在任何指定的時間點都有一些使用量,則可同時到達尖峰的資料庫會少於 2/3 (或 67%)。If all databases have some utilization at any given point in time, then less than 2/3 (or 67%) of the databases can peak simultaneously.

每個資料庫的資源使用量Resource utilization per database

資料庫的尖峰和平均使用量之間的差異為,長時間的低使用量和短時間的高使用量。A large difference between the peak and average utilization of a database indicates prolonged periods of low utilization and short periods of high utilization. 這個使用量模式非常適合在資料庫之間共用資源。This utilization pattern is ideal for sharing resources across databases. 若資料庫的尖峰使用量為平均使用量的 1.5 倍大,就應該將該資料庫視為集區。A database should be considered for a pool when its peak utilization is about 1.5 times greater than its average utilization.

DTU 為基礎的購買模型範例尖峰至 100 Dtu 且平均使用 67 Dtu 或更低的 S3 資料庫,是在集區中共用 Edtu 的理想候選。DTU-based purchasing model example An S3 database that peaks to 100 DTUs and on average uses 67 DTUs or less is a good candidate for sharing eDTUs in a pool. 或者,尖峰為 20 個 DTU 且平均使用 13 個 DTU 或更少的 S1 資料庫是集區的良好候選項目。Alternatively, an S1 database that peaks to 20 DTUs and on average uses 13 DTUs or less is a good candidate for a pool.

如何選擇正確的集區大小How do I choose the correct pool size

集區的最佳大小取決於集區中所有資料庫所需的彙總資源。The best size for a pool depends on the aggregate resources needed for all databases in the pool. 這牽涉到決定下列各項:This involves determining the following:

  • 集區中所有資料庫所使用的資源上限 (最大 Dtu 或最大虛擬核心,視您選擇的購買模型) 而定。Maximum resources utilized by all databases in the pool (either maximum DTUs or maximum vCores depending on your choice of purchasing model).
  • 集區中所有資料庫使用的最大儲存體位元組。Maximum storage bytes utilized by all databases in the pool.

如需每個資源模型的可用服務層級和限制,請參閱以 DTU 為基礎的購買模型 或以 vCore 為基礎的購買模型For available service tiers and limits for each resource model, see the DTU-based purchasing model or the vCore-based purchasing model.

下列步驟可協助您預估集區是否比單一資料庫更符合成本效益:The following steps can help you estimate whether a pool is more cost-effective than single databases:

  1. 估計集區所需的 eDTU 或虛擬核心,如下所示:Estimate the eDTUs or vCores needed for the pool as follows:

對於以 DTU 為基礎的購買模型:For DTU-based purchasing model:

最大 ( # Total number of DBs B0每個 DB 的平均 DTU 使用率>,<並行尖峰Db x每個 db 的尖峰 dtu 使用率>) MAX(<Total number of DBs X average DTU utilization per DB>, <Number of concurrently peaking DBs X Peak DTU utilization per DB>)

對於以虛擬核心為基礎的購買模型:For vCore-based purchasing model:

MAX ( # B0 Total number of DBs 每個 Db 的平均 vCore 使用率>,<同時尖峰db x尖峰 vCore 使用量(每個 db>)) MAX(<Total number of DBs X average vCore utilization per DB>, <Number of concurrently peaking DBs X Peak vCore utilization per DB>)

  1. 加總集區中所有資料庫所需的位元組數目,以估計集區所需的儲存空間。Estimate the storage space needed for the pool by adding the number of bytes needed for all the databases in the pool. 然後判斷可提供此儲存體數量的 eDTU 集區大小。Then determine the eDTU pool size that provides this amount of storage.
  2. 針對以 DTU 為基礎的購買模型,採用步驟 1 和步驟 2 中較大的 eDTU 估計值。For the DTU-based purchasing model, take the larger of the eDTU estimates from Step 1 and Step 2. 針對以虛擬核心為基礎的購買模型,採用步驟 1 中的虛擬核心估計值。For the vCore-based purchasing model, take the vCore estimate from Step 1.
  3. 請參閱 SQL Database 價格頁面並尋找大於步驟 3 估計值的最小集區大小。See the SQL Database pricing page and find the smallest pool size that is greater than the estimate from Step 3.
  4. 將步驟 5 的集區價格與單一資料庫適當計算大小的價格相比較。Compare the pool price from Step 5 to the price of using the appropriate compute sizes for single databases.


如果集區中的資料庫數目接近支援的最大值,請務必考慮使用 密集彈性集區中的資源管理If the number of databases in a pool approaches the maximum supported, make sure to consider Resource management in dense elastic pools.

搭配彈性集區使用其他的 SQL Database 功能Using other SQL Database features with elastic pools

彈性作業和彈性集區Elastic jobs and elastic pools

使用集區,只要在**彈性作業** 中執行指令碼,就能簡化管理工作。With a pool, management tasks are simplified by running scripts in elastic jobs. 彈性作業會消除與大量資料庫相關聯的冗長工作。An elastic job eliminates most of tedium associated with large numbers of databases.

如需可供使用多個資料庫之其他資料庫工具的詳細資訊,請參閱使用Azure SQL Database 向上調整For more information about other database tools for working with multiple databases, see Scaling out with Azure SQL Database.

彈性集區之中的資料庫所適用的業務持續性選項Business continuity options for databases in an elastic pool

集區資料庫通常會支援單一資料庫可用的相同商務持續性功能Pooled databases generally support the same business continuity features that are available to single databases.

使用 Azure 入口網站建立新的 SQL Database 彈性集區Creating a new SQL Database elastic pool using the Azure portal

在 Azure 入口網站中建立彈性集區的方式有兩種。There are two ways you can create an elastic pool in the Azure portal.

  1. 移至 Azure 入口網站 以建立彈性集區。Go to the Azure portal to create an elastic pool. 搜尋並選取 AZURE SQLSearch for and select Azure SQL.

  2. 選取 [+ 新增] 以開啟 [選取 SQL 部署選項] 頁面。Select +Add to open the Select SQL deployment option page. 您可以選取 [資料庫] 磚上的 [顯示詳細資料],以查看彈性集區的其他相關資訊。You can view additional information about elastic pools by selecting Show details on the Databases tile.

  3. 在 [資料庫] 磚的 [資源類型] 下拉式清單中,選取 [彈性集區],然後選取 [建立On the Databases tile, select Elastic pool in the Resource type dropdown, then select Create:


  4. 或者,您可以流覽至現有伺服器,然後按一下 [ + 新增集 區],直接在該伺服器中建立集區,以建立彈性集區。Or you can create an elastic pool by navigating to an existing server and clicking + New pool to create a pool directly into that server.


您可以在伺服器上建立多個集區,但無法將來自不同伺服器的資料庫新增到相同的集區。You can create multiple pools on a server, but you can't add databases from different servers into the same pool.

集區的服務層級決定了集區中彈性資料庫可用的功能,以及每個資料庫可用的資源數目上限。The pool's service tier determines the features available to the elastics in the pool, and the maximum amount of resources available to each database. 如需詳細資訊,請參閱 DTU 模型中彈性集區的資源限制。For details, see Resource limits for elastic pools in the DTU model. 如需彈性集區以虛擬核心為基礎的資源限制,請參閱以虛擬核心為基礎的資源限制 - 彈性集區For vCore-based resource limits for elastic pools, see vCore-based resource limits - elastic pools.

若要設定集區的資源和定價,請按一下 [設定集區]****。To configure the resources and pricing of the pool, click Configure pool. 然後選取服務層級、將資料庫新增至集區,以及為集區及其資料庫設定資源限制。Then select a service tier, add databases to the pool, and configure the resource limits for the pool and its databases.

當您完成設定集區時,您可以按一下 [套用],為集區命名,然後按一下 [確定] 以建立集區。When you have completed configuring the pool, you can click 'Apply', name the pool, and click 'OK' to create the pool.

監視彈性集區及其資料庫Monitor an elastic pool and its databases

在 Azure 入口網站中,您可以監視彈性集區與集區內資料庫的使用率。In the Azure portal, you can monitor the utilization of an elastic pool and the databases within that pool. 也可以對彈性集區進行一些變更,並且一次提交所有的變更。You can also make a set of changes to your elastic pool and submit all changes at the same time. 這些變更包括新增或移除資料庫、變更您的彈性集區設定,或變更您的資料庫設定。These changes include adding or removing databases, changing your elastic pool settings, or changing your database settings.

若要開始監視您的彈性集區,請在入口網站中尋找並開啟彈性集區。To start monitoring your elastic pool, find and open an elastic pool in the portal. 您會先看到一個畫面,讓您瞭解彈性集區的狀態。You'll first see a screen that gives you an overview of the status of your elastic pool. 這包括:This includes:

  • 監視圖表會顯示彈性集區的資源使用量Monitoring charts showing resources usage of the elastic pool
  • 彈性集區的最近警示和建議 (如果有的話)Recent alerts and recommendations, if available, for the elastic pool

下圖顯示範例彈性集區:The following graphic shows an example elastic pool:


如果您想要更多有關集區的資訊,您可以在此概觀中按一下任何可用資訊。If you want more information about the pool you can click on any of the available information in this overview. 按一下 [資源使用量]**** 圖表,系統將會帶您前往 [Azure 監視] 檢視,您可以在那裡自訂圖表中顯示的計量和時間範圍。Clicking on the Resource utilization chart will take you to the Azure Monitoring view where you can customize the metrics and time window shown in the chart. 按一下任何可用的通知,系統將會帶您前往一個刀鋒視窗,其中顯示該警示或建議的完整詳細資料。Clicking on any available notifications will take you to a blade that shows the full details of that alert or recommendation.

如果您想要監視集區內的資料庫,您可以按一下左側資源功能表上 [監視]**** 區段中的 [資料庫資源使用量]****。If you would like to monitor the databases inside your pool, you can click on Database resource utilization in the Monitoring section of the resource menu on the left.


自訂圖表顯示To customize the chart display

您可以編輯此圖表和 [計量] 頁面,以顯示其他計量,例如所用的 CPU 百分比、資料 IO 百分比和記錄 IO 百分比。You can edit the chart and the metric page to display other metrics such as CPU percentage, data IO percentage, and log IO percentage used.

在 [編輯圖表]**** 表單上,您可以選取固定時間範圍,或按一下 [自訂]**** 以選取最近兩週內的任何 24 小時範圍,然後選取要監視的資源。On the Edit Chart form, you can select a fixed time range or click custom to select any 24-hour window in the last two weeks, and then select the resources to monitor.

選取要監視的資料庫To select databases to monitor

根據預設,[資料庫資源使用量]**** 刀鋒視窗中的圖表會依照 DTU 或 CPU (取決於您的服務層級) 顯示前 5 名資料庫。By default, the chart in the Database Resource Utilization blade will show the top 5 databases by DTU or CPU (depending on your service tier). 您可以在此圖表中切換資料庫,方法是透過左側的核取方塊,從圖表下方的清單中選取和取消選取資料庫。You can switch up the databases in this chart by selecting and unselecting databases from the list below the chart via the checkboxes on the left.

您也可以選取更多計量,以在此資料庫資料表中並列檢視,進而取得更完整的資料庫效能檢視。You can also select more metrics to view side by side in this database table to get a more complete view of your databases performance.

如需詳細資訊,請參閱在 Azure 入口網站中建立 SQL Database 警示For more information, see create SQL Database alerts in Azure portal.

客戶案例研究Customer case studies

  • SnelStartSnelStart

    SnelStart 搭配 Azure SQL Database 使用彈性集區,以每月1000個新 Azure SQL database 的費率快速擴充其商務服務。SnelStart used elastic pools with Azure SQL Database to rapidly expand its business services at a rate of 1,000 new Azure SQL databases per month.

  • UmbracoUmbraco

    Umbraco 使用具有 Azure SQL Database 的彈性集區,為雲端中數以千計的租使用者快速布建和擴充服務。Umbraco uses elastic pools with Azure SQL Database to quickly provision and scale services for thousands of tenants in the cloud.

  • Daxko/CSIDaxko/CSI

    Daxko/CSI 使用具有 Azure SQL Database 的彈性集區來加速其開發週期,並增強其客戶服務和效能。Daxko/CSI uses elastic pools with Azure SQL Database to accelerate its development cycle and to enhance its customer services and performance.

後續步驟Next steps