選擇 vCore 和 DTU 購買模型-Azure SQL Database 和 SQL 受控執行個體Choose between the vCore and DTU purchasing models - Azure SQL Database and SQL Managed Instance

適用於: Azure SQL Database Azure SQL 受控執行個體

Azure SQL Database 和 Azure SQL 受控執行個體可讓您輕鬆地購買完全受控的平臺即服務 (PaaS) Database engine,以符合您的效能和成本需求。Azure SQL Database and Azure SQL Managed Instance let you easily purchase a fully managed platform as a service (PaaS) database engine that fits your performance and cost needs. 根據您為 Azure SQL Database 選擇的部署模型,您可以選取適合您的購買模型:Depending on the deployment model you've chosen for Azure SQL Database, you can select the purchasing model that works for you:

  • 虛擬核心 (vCore) 為基礎的購買模型 (建議的) 。Virtual core (vCore)-based purchasing model (recommended). 此購買模型可讓您選擇布建的計算層和無伺服器計算層。This purchasing model provides a choice between a provisioned compute tier and a serverless compute tier. 在布建的計算層中,您可以選擇一律針對您的工作負載布建的確切計算資源量。With the provisioned compute tier, you choose the exact amount of compute resources that are always provisioned for your workload. 使用無伺服器計算層級,您可以透過可設定的計算範圍來指定計算資源的自動調整。With the serverless compute tier, you specify the autoscaling of the compute resources over a configurable compute range. 使用此計算層,您也可以根據工作負載活動自動暫停和繼續資料庫。With this compute tier, you can also automatically pause and resume the database based on workload activity. 布建的計算層級中,每個時間單位的 vCore 單位價格低於無伺服器計算層級。The vCore unit price per unit of time is lower in the provisioned compute tier than it is in the serverless compute tier.
  • 資料庫交易單位 (DTU) 為基礎的購買模型Database transaction unit (DTU)-based purchasing model. 此購買模型提供適用于一般工作負載的配套計算和儲存體套件。This purchasing model provides bundled compute and storage packages balanced for common workloads.

有兩種購買模型:There are two purchasing models:

下表和圖表比較和對比 vCore 型和以 DTU 為基礎的購買模型:The following table and chart compare and contrast the vCore-based and the DTU-based purchasing models:

購買模型Purchasing model 說明Description 適用對象Best for
以 DTU 為基礎DTU-based 此模型是以計算、儲存體和 i/o 資源的配套量值為基礎。This model is based on a bundled measure of compute, storage, and I/O resources. DTU 的計算大小會以資料庫交易單位 (DTU) 表示,而彈性集區的計算大小則會以彈性資料庫交易單位 (eDTU) 表示。Compute sizes are expressed in DTUs for single databases and in elastic database transaction units (eDTUs) for elastic pools. 如需 DTU 與 eDTU 的相關資訊,請參閱 什麼是 DTU 與 eDTU?For more information about DTUs and eDTUs, see What are DTUs and eDTUs?. 需要簡單、預先設定之資源選項的客戶Customers who want simple, preconfigured resource options
以 vCore 為基礎vCore-based 此模型可讓您獨立地選擇計算和儲存體資源。This model allows you to independently choose compute and storage resources. 以虛擬核心為基礎的購買模型也可讓您使用適用於 SQL Server 的 Azure Hybrid Benefit,以節省成本。The vCore-based purchasing model also allows you to use Azure Hybrid Benefit for SQL Server to save costs. 彈性、控制和透明度的價值客戶Customers who value flexibility, control, and transparency

定價模型比較

想要最佳化並節省您的雲端費用嗎?Want to optimize and save on your cloud spending?

Azure 服務成本費用。Azure services cost money. Azure 成本管理可協助您設定預算和設定警示以控制費用。Azure Cost Management helps you set budgets and configure alerts to keep spending under control. 使用成本管理來分析、管理和最佳化您的 Azure 成本。Analyze, manage, and optimize your Azure costs with Cost Management. 若要深入了解,請參閱分析成本的快速入門To learn more, see the quickstart on analyzing your costs.

計算成本Compute costs

布建的計算成本Provisioned compute costs

在布建的計算層中,計算成本會反映為應用程式布建的計算容量總計。In the provisioned compute tier, the compute cost reflects the total compute capacity that is provisioned for the application.

在業務關鍵服務層級中,我們會自動設定至少三個複本。In the Business Critical service tier, we automatically allocate at least three replicas. 為了反映這項額外的計算資源配置,以 vCore 為基礎的購買模型中的價格大約比一般用途服務層級的商務關鍵服務層級中的2.7 倍高。To reflect this additional allocation of compute resources, the price in the vCore-based purchasing model is approximately 2.7 times higher in the Business Critical service tier than it is in the General Purpose service tier. 同樣地,商務關鍵服務層級中的每 GB 儲存體價格越高,也會反映出更高的 IO 限制和 SSD 儲存體的較低延遲。Likewise, the higher storage price per GB in the Business Critical service tier reflects the higher IO limits and lower latency of the SSD storage.

對於業務關鍵服務層級和一般用途服務層級,備份儲存體的成本相同,因為這兩個層級會使用標準儲存體進行備份。The cost of backup storage is the same for the Business Critical service tier and the General Purpose service tier because both tiers use standard storage for backups.

無伺服器計算成本Serverless compute costs

如需計算容量的定義方式,以及如何計算無伺服器計算層費用的說明,請參閱 SQL Database 無伺服器層For a description of how compute capacity is defined and costs are calculated for the serverless compute tier, see SQL Database serverless tier.

儲存體成本Storage costs

不同類型的儲存體會以不同方式計費。Different types of storage are billed differently. 對於資料儲存體,您必須根據所選的資料庫或集區大小上限,為布建的儲存體支付費用。For data storage, you're charged for the provisioned storage based upon the maximum database or pool size you select. 除非您減少或增加該上限,否則成本不會變更。The cost doesn't change unless you reduce or increase that maximum. 備份儲存體與您執行個體的自動備份相關聯,而且是動態配置的。Backup storage is associated with automated backups of your instance and is allocated dynamically. 增加您的備份保留期限,可增加實例所耗用的備份儲存體。Increasing your backup-retention period increases the backup storage that's consumed by your instance.

根據預設,系統會將您資料庫的7天自動備份複製到讀取權限異地冗余儲存體, (GRS) 標準 Blob 儲存體帳戶。By default, seven days of automated backups of your databases are copied to a read-access geo-redundant storage (RA-GRS) standard Blob storage account. 每週完整備份、每日差異備份,以及每隔五分鐘複製一次的交易記錄備份都使用此儲存體。This storage is used by weekly full backups, daily differential backups, and transaction log backups, which are copied every five minutes. 交易記錄檔的大小取決於資料庫的變動率。The size of the transaction logs depends on the rate of change of the database. 提供的最小儲存體數量等於資料庫大小的100%,不需額外費用。A minimum storage amount equal to 100 percent of the database size is provided at no extra charge. 備份儲存體的額外使用量,會按月以 GB 為單位收費。Additional consumption of backup storage is charged in GB per month.

如需儲存體價格的詳細資訊,請參閱定價頁面。For more information about storage prices, see the pricing page.

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

虛擬核心 (vCore) 代表邏輯 CPU,並可讓您選擇硬體世代和 (硬體的實體特性,例如,核心數目、記憶體和儲存體大小) 。A virtual core (vCore) represents a logical CPU and offers you the option to choose between generations of hardware and the physical characteristics of the hardware (for example, the number of cores, the memory, and the storage size). VCore 為基礎的購買模型為您提供彈性、控制、透明的個別資源耗用量,以及將內部部署工作負載需求轉譯至雲端的簡單方式。The vCore-based purchasing model gives you flexibility, control, transparency of individual resource consumption, and a straightforward way to translate on-premises workload requirements to the cloud. 此模型可讓您根據您的工作負載需求,選擇計算、記憶體和儲存體資源。This model allows you to choose compute, memory, and storage resources based on your workload needs.

在以 vCore 為基礎的購買模型中,您可以選擇 SQL Database 和 SQL 受控執行個體的 一般用途業務關鍵 服務層級。In the vCore-based purchasing model, you can choose between the General Purpose and Business Critical service tiers for SQL Database and SQL Managed Instance. 若為單一資料庫,您也可以選擇 超大規模服務層級For single databases, you can also choose the Hyperscale service tier.

VCore 為基礎的購買模型可讓您獨立地選擇計算和儲存體資源、符合內部部署效能,並將價格優化。The vCore-based purchasing model lets you independently choose compute and storage resources, match on-premises performance, and optimize price. 在以 vCore 為基礎的購買模型中,您需要支付:In the vCore-based purchasing model, you pay for:

  • 計算資源 (服務層級 + 虛擬核心數目和記憶體數量 + 硬體世代)。Compute resources (the service tier + the number of vCores and the amount of memory + the generation of hardware).
  • 資料和記錄儲存體的類型和數量。The type and amount of data and log storage.
  • 備份儲存體 (RA-GRS) 。Backup storage (RA-GRS).

重要

計算資源、i/o 和資料和記錄儲存體都會依資料庫或彈性集區收費。Compute resources, I/O, and data and log storage are charged per database or elastic pool. 備份儲存體是依每個資料庫計費。Backup storage is charged per each database. 如需 SQL 受控執行個體費用的詳細資訊,請參閱 sql 受控執行個體For more information about SQL Managed Instance charges, see SQL Managed Instance. 區域限制: 如需目前支援的區域清單,請參閱 依區域提供的產品Region limitations: For the current list of supported regions, see products available by region. 若要在目前不支援的區域中建立受控實例,請透過 Azure 入口網站傳送支援要求To create a managed instance in a region that currently isn't supported, send a support request via the Azure portal.

如果您的資料庫耗用超過 300 Dtu,則轉換成 vCore 為基礎的購買模型可能會降低您的成本。If your database consumes more than 300 DTUs, converting to the vCore-based purchasing model might reduce your costs. 您可以使用您選擇的 API 或使用 Azure 入口網站來進行轉換,而不需要停機。You can convert by using your API of choice or by using the Azure portal, with no downtime. 不過,轉換並不是必要的,而且不會自動完成。However, conversion isn't required and isn't done automatically. 如果以 DTU 為基礎的購買模型符合您的效能和商務需求,請繼續使用即可。If the DTU-based purchasing model meets your performance and business requirements, you should continue using it.

若要從以 DTU 為基礎的購買模型轉換為 vCore 為基礎的購買模型,請參閱 從 Dtu 遷移至 vCoreTo convert from the DTU-based purchasing model to the vCore-based purchasing model, see Migrate from DTU to vCore.

以 DTU 為基礎的購買模型DTU-based purchasing model

資料庫交易單位 (DTU) 代表 CPU、記憶體、讀取和寫入的混合量值。A database transaction unit (DTU) represents a blended measure of CPU, memory, reads, and writes. 以 DTU 為基礎的購買模型會提供一組預先設定好的計算資源組合和所包含的儲存體,以期達成不同的應用程式效能等級。The DTU-based purchasing model offers a set of preconfigured bundles of compute resources and included storage to drive different levels of application performance. 如果您偏好預先設定的組合和每個月的固定付款,以 DTU 為基礎的模型可能更適合您的需求。If you prefer the simplicity of a preconfigured bundle and fixed payments each month, the DTU-based model might be more suitable for your needs.

在以 DTU 為基礎的購買模型中,您可以選擇 Azure SQL Database 的基本、標準和 premium 服務層。In the DTU-based purchasing model, you can choose between the basic, standard, and premium service tiers for Azure SQL Database. 以 DTU 為基礎的購買模型不適用於 Azure SQL 受控執行個體。The DTU-based purchasing model isn't available for Azure SQL Managed Instance.

資料庫交易單位 (DTU)Database transaction units (DTUs)

針對 服務層級中特定計算大小的單一資料庫,azure 保證該資料庫的特定資源層級 (與 Azure 雲端) 中的其他任何資料庫無關。For a single database at a specific compute size within a service tier, Azure guarantees a certain level of resources for that database (independent of any other database in the Azure cloud). 這項保證可提供可預測的效能等級。This guarantee provides a predictable level of performance. 針對資料庫所配置的資源數量會計算為 Dtu 數目,並且是計算、儲存體和 i/o 資源的配套量值。The amount of resources allocated for a database is calculated as a number of DTUs and is a bundled measure of compute, storage, and I/O resources.

這些資源的比率,原本是由 線上交易處理所決定, (OLTP) 效能評定工作負載 ,其設計目的是真實世界的 oltp 工作負載。The ratio among these resources is originally determined by an online transaction processing (OLTP) benchmark workload designed to be typical of real-world OLTP workloads. 當您的工作負載超過上述任何資源的數量時,您的輸送量會受到節流處理,導致效能變慢和超時時間。When your workload exceeds the amount of any of these resources, your throughput is throttled, resulting in slower performance and time-outs.

您的工作負載所使用的資源,不會影響 Azure 雲端中其他資料庫可用的資源。The resources used by your workload don't impact the resources available to other databases in the Azure cloud. 同樣地,其他工作負載所使用的資源也不會影響您資料庫可用的資源。Likewise, the resources used by other workloads don't impact the resources available to your database.

週框方塊

Dtu 最適合用來瞭解針對不同計算大小和服務層級的資料庫所配置的相對資源。DTUs are most useful for understanding the relative resources that are allocated for databases at different compute sizes and service tiers. 例如:For example:

  • 藉由增加資料庫的計算大小來使 Dtu 加倍,等於讓該資料庫可用的資源集合加倍。Doubling the DTUs by increasing the compute size of a database equates to doubling the set of resources available to that database.
  • 具有 1750 Dtu 的高階服務層 P11 資料庫提供350倍以上的 DTU 計算能力,而非具有5個 Dtu 的基本服務層資料庫。A premium service tier P11 database with 1750 DTUs provides 350 times more DTU compute power than a basic service tier database with 5 DTUs.

若要深入瞭解資源 (DTU) 取用工作負載,請使用 查詢效能深入 解析來:To gain deeper insight into the resource (DTU) consumption of your workload, use query-performance insights to:

  • 依據 CPU/持續時間/執行計數,找出可調整以改善效能的排名最前面的查詢。Identify the top queries by CPU/duration/execution count that can potentially be tuned for improved performance. 例如,需要大量 i/o 的查詢可能會受益于 記憶體中的優化技術 ,以便在特定服務層級和計算大小更妥善地使用可用的記憶體。For example, an I/O-intensive query might benefit from in-memory optimization techniques to make better use of the available memory at a certain service tier and compute size.
  • 向下切入查詢的詳細資料,以查看其文字和其資源使用量歷程記錄。Drill down into the details of a query to view its text and its history of resource usage.
  • 存取效能微調建議,以顯示 SQL Database Advisor所採取的動作。Access performance-tuning recommendations that show actions taken by SQL Database Advisor.

彈性資料庫交易單位 (Edtu) Elastic database transaction units (eDTUs)

針對永遠可用的資料庫,而不是提供一組專用的資源 (Dtu) 可能不一定需要,您可以將這些資料庫放在 彈性集區中。For databases that are always available, rather than provide a dedicated set of resources (DTUs) that might not always be needed, you can place these databases into an elastic pool. 彈性集區中的資料庫位於單一伺服器上,並共用資源集區。The databases in an elastic pool are on a single server and share a pool of resources.

彈性集區中的共用資源,是以彈性資料庫交易單位 (Edtu) 來測量。The shared resources in an elastic pool are measured by elastic database transaction units (eDTUs). 彈性集區提供簡單且符合成本效益的解決方案,以管理多個資料庫的效能目標,而這些資料庫具有廣泛變化且無法預測的使用模式。Elastic pools provide a simple, cost-effective solution to manage performance goals for multiple databases that have widely varying and unpredictable usage patterns. 彈性集區可確保集區中的一個資料庫無法取用所有資源,同時確保集區中的每個資料庫一律具有最少量的必要資源可用。An elastic pool guarantees that all the resources can't be consumed by one database in the pool, while ensuring that each database in the pool always has a minimum amount of necessary resources available.

集區以固定價格提供固定數目的 eDTU。A pool is given a set number of eDTUs for a set price. 在彈性集區中,個別資料庫可以在設定的界限內自動調整。In the elastic pool, individual databases can autoscale within the configured boundaries. 較繁重負載下的資料庫將會耗用更多 Edtu 來滿足需求。A database under a heavier load will consume more eDTUs to meet demand. 較輕量負載下的資料庫會耗用較少的 Edtu。Databases under lighter loads will consume fewer eDTUs. 沒有負載的資料庫不會取用 eDTU。Databases with no load will consume no eDTUs. 由於系統會針對整個集區布建資源,而不是針對每個資料庫布建,因此彈性集區會簡化您的管理工作,並提供可預測的集區預算。Because resources are provisioned for the entire pool, rather than per database, elastic pools simplify your management tasks and provide a predictable budget for the pool.

您可以將其他 Edtu 新增至現有集區,而不會造成資料庫停機,且不會影響集區中的資料庫。You can add additional eDTUs to an existing pool with no database downtime and with no impact on the databases in the pool. 同樣地,如果您不再需要額外的 Edtu,請隨時從現有的集區中移除它們。Similarly, if you no longer need extra eDTUs, remove them from an existing pool at any time. 您也可以隨時在集區中新增或減少資料庫。You can also add databases to or subtract databases from a pool at any time. 若要保留其他資料庫的 Edtu,請限制資料庫在繁重負載下可使用的 Edtu 數目。To reserve eDTUs for other databases, limit the number of eDTUs a database can use under a heavy load. 如果資料庫一致地 underuses 資源,請將其移出集區,並將它設定為具有可預測的必要資源量的單一資料庫。If a database consistently underuses resources, move it out of the pool and configure it as a single database with a predictable amount of required resources.

判斷工作負載所需的 DTU 數目Determine the number of DTUs needed by a workload

如果您想要將現有的內部部署或 SQL Server 的虛擬機器工作負載遷移到 SQL Database,請使用 dtu 計算機 來估計所需的 dtu 數目。If you want to migrate an existing on-premises or SQL Server virtual machine workload to SQL Database, use the DTU calculator to approximate the number of DTUs needed. 針對現有的 SQL Database 工作負載,請使用 查詢效能深入 解析來瞭解您的資料庫資源耗用量 (dtu) 並取得更深入的見解,以優化您的工作負載。For an existing SQL Database workload, use query-performance insights to understand your database-resource consumption (DTUs) and gain deeper insights for optimizing your workload. Sys.dm_db_resource_stats動態管理檢視 (DMV) 可讓您查看過去一小時的資源耗用量。The sys.dm_db_resource_stats dynamic management view (DMV) lets you view resource consumption for the last hour. [ Sys.resource_stats 目錄] 視圖會顯示過去14天的資源耗用量,但以較低的精確度表示五分鐘的平均值。The sys.resource_stats catalog view displays resource consumption for the last 14 days, but at a lower fidelity of five-minute averages.

判斷 DTU 使用量Determine DTU utilization

若要判斷 DTU/eDTU 使用量的平均百分比(相對於資料庫或彈性集區的 DTU/eDTU 限制),請使用下列公式:To determine the average percentage of DTU/eDTU utilization relative to the DTU/eDTU limit of a database or an elastic pool, use the following formula:

avg_dtu_percent = MAX(avg_cpu_percent, avg_data_io_percent, avg_log_write_percent)

您可以從 sys.dm_db_resource_statsSys.resource_statssys.elastic_pool_resource_stats dmv 取得此公式的輸入值。The input values for this formula can be obtained from sys.dm_db_resource_stats, sys.resource_stats, and sys.elastic_pool_resource_stats DMVs. 換句話說,若要判斷 DTU/eDTU 使用量對資料庫或彈性集區的 DTU/eDTU 限制的百分比,請從下列位置挑選最大的百分比值: avg_cpu_percentavg_data_io_percent 以及 avg_log_write_percent 在指定的時間點。In other words, to determine the percentage of DTU/eDTU utilization toward the DTU/eDTU limit of a database or an elastic pool, pick the largest percentage value from the following: avg_cpu_percent, avg_data_io_percent, and avg_log_write_percent at a given point in time.

注意

資料庫的 DTU 限制取決於資料庫可用的 CPU、讀取、寫入和記憶體。The DTU limit of a database is determined by CPU, reads, writes, and memory available to the database. 不過,因為 SQL Database 引擎通常會使用所有可用的記憶體來進行資料快取,以改善效能,所以 avg_memory_usage_percent 不論目前的資料庫負載為何,此值通常會接近100%。However, because the SQL Database engine typically uses all available memory for its data cache to improve performance, the avg_memory_usage_percent value will usually be close to 100 percent, regardless of current database load. 因此,即使記憶體間接影響 DTU 限制,也不會在 DTU 使用率公式中使用。Therefore, even though memory does indirectly influence the DTU limit, it is not used in the DTU utilization formula.

能受益於彈性資源集區的工作負載Workloads that benefit from an elastic pool of resources

集區非常適合具有低資源使用率平均和相對不頻繁使用率尖峰的資料庫。Pools are well suited for databases with a low resource-utilization average and relatively infrequent utilization spikes. 如需詳細資訊,請參閱 何時應該考慮 SQL Database 彈性集區?For more information, see When should you consider a SQL Database elastic pool?.

以 DTU 為基礎的購買模型中的硬體世代Hardware generations in the DTU-based purchasing model

在以 DTU 為基礎的購買模型中,客戶無法選擇用於其資料庫的硬體世代。In the DTU-based purchasing model, customers cannot choose the hardware generation used for their databases. 雖然指定的資料庫通常會維持在特定硬體世代上, (通常會有數個月的時間) ,但有些事件可能會導致資料庫移至另一個硬體世代。While a given database usually stays on a specific hardware generation for a long time (commonly for multiple months), there are certain events that can cause a database to be moved to another hardware generation.

例如,如果資料庫相應增加或減少至不同的服務目標,或是資料中心內目前的基礎結構已接近其容量限制,或目前使用的硬體因為生命週期結束而解除委任,則可以將資料庫移至不同的硬體世代。For example, a database can be moved to a different hardware generation if it's scaled up or down to a different service objective, or if the current infrastructure in a datacenter is approaching its capacity limits, or if the currently used hardware is being decommissioned due to its end of life.

如果資料庫移至不同的硬體,工作負載效能可能會變更。If a database is moved to different hardware, workload performance can change. DTU 模型可保證 dtu 效能評定工作負載的輸送量和回應時間,在資料庫移至不同的硬體世代時,會保持完全相同,只要其服務目標 (dtu 數目) 維持不變。The DTU model guarantees that the throughput and response time of the DTU benchmark workload will remain substantially identical as the database moves to a different hardware generation, as long as its service objective (the number of DTUs) stays the same.

不過,在 Azure SQL Database 中執行的廣泛客戶工作負載中,針對相同的服務目標使用不同硬體的影響可能更明顯。However, across the wide spectrum of customer workloads running in Azure SQL Database, the impact of using different hardware for the same service objective can be more pronounced. 不同的工作負載將受益于不同的硬體設定和功能。Different workloads will benefit from different hardware configuration and features. 因此,針對 DTU 基準測試以外的工作負載,如果資料庫從一個硬體世代移至另一個硬體,就可能會看到效能差異。Therefore, for workloads other than the DTU benchmark, it's possible to see performance differences if the database moves from one hardware generation to another.

例如,對網路延遲敏感的應用程式可能會在第5代硬體與第4代上看到更佳的效能,因為在第5代中使用加速網路,但使用大量讀取 IO 的應用程式在第4代硬體與第5代上可能會看到較佳的效能,因為第4代上的每個核心比例會有較高的記憶體。For example, an application that is sensitive to network latency can see better performance on Gen5 hardware vs. Gen4 due to the use of Accelerated Networking in Gen5, but an application using intensive read IO can see better performance on Gen4 hardware versus Gen5 due to a higher memory per core ratio on Gen4.

如果客戶的工作負載受到硬體變更的影響,或想要控制其資料庫之硬體世代選擇的客戶,則可以使用 vCore 模型,在資料庫建立和調整期間選擇其慣用的硬體世代。Customers with workloads that are sensitive to hardware changes or customers who wish to control the choice of hardware generation for their database can use the vCore model to choose their preferred hardware generation during database creation and scaling. 在 vCore 模型中,會針對 單一資料庫彈性集區記錄每個硬體世代上每個服務目標的資源限制。In the vCore model, resource limits of each service objective on each hardware generation are documented, for both single databases and elastic pools. 如需 vCore 模型中硬體世代的詳細資訊,請參閱 硬體世代。For more information about hardware generations in the vCore model, see Hardware generations.

常見問題集 (FAQ)Frequently asked questions (FAQs)

我是否需要讓我的應用程式離線,才能從以 DTU 為基礎的服務層級轉換為以 vCore 為基礎的服務層級?Do I need to take my application offline to convert from a DTU-based service tier to a vCore-based service tier?

否。No. 您不需要讓應用程式離線。You don't need to take the application offline. 新的服務層級提供簡單的線上轉換方法,類似于將資料庫從標準升級至 premium 服務層的現有程式,以及其他方式。The new service tiers offer a simple online-conversion method that's similar to the existing process of upgrading databases from the standard to the premium service tier and the other way around. 您可以使用 Azure 入口網站、PowerShell、Azure CLI、T-sql 或 REST API 來開始這項轉換。You can start this conversion by using the Azure portal, PowerShell, the Azure CLI, T-SQL, or the REST API. 請參閱 管理單一資料庫管理彈性集區。See Manage single databases and Manage elastic pools.

是否可以將資料庫從 vCore 為基礎的購買模型中的服務層,轉換成以 DTU 為基礎的購買模型中的服務層級?Can I convert a database from a service tier in the vCore-based purchasing model to a service tier in the DTU-based purchasing model?

是的,您可以使用 Azure 入口網站、PowerShell、Azure CLI、T-sql 或 REST API,輕鬆地將資料庫轉換為任何支援的效能目標。Yes, you can easily convert your database to any supported performance objective by using the Azure portal, PowerShell, the Azure CLI, T-SQL, or the REST API. 請參閱 管理單一資料庫管理彈性集區。See Manage single databases and Manage elastic pools.

後續步驟Next steps