選擇 虛擬核心服務層,並從 DTU 服務層移轉Choose among the vCore service tiers and migrate from the DTU service tiers

虛擬核心 (vCore) 為基礎的購買模型可讓您獨立調整計算和儲存體資源、 符合內部部署的效能,並獲得最佳價格。The virtual core (vCore)-based purchasing model lets you independently scale compute and storage resources, match on-premises performance, and optimize price. 它也可讓您選擇的硬體世代:It also lets you choose the generation of hardware:

  • 第 4 代:最多 24 的邏輯 Cpu 根據 Intel E5 2673 v3 (Haswell) 2.4-GHz 處理器,vCore = 1 PP (實體核心),每個核心,7GB 附加 SSDGen4: Up to 24 logical CPUs based on Intel E5-2673 v3 (Haswell) 2.4-GHz processors, vCore = 1 PP (physical core), 7 GB per core, attached SSD
  • 第 5 代:最多 80 的邏輯 Cpu 根據 Intel E5 2673 v4 (Broadwell) 2.3-GHz 處理器,vCore = 1 LP (超-執行緒),每個核心,快速 eNVM SSD 5.1 GBGen5: Up to 80 logical CPUs based on Intel E5-2673 v4 (Broadwell) 2.3-GHz processors, vCore = 1 LP (hyper-thread), 5.1 GB per core, fast eNVM SSD

在 Gen4 硬體中,每個虛擬核心的記憶體會高出許多。Gen4 hardware offers substantially more memory per vCore. 不過,Gen5 硬體可讓您大幅相應增加計算資源。However, Gen5 hardware allows you to scale up compute resources much higher.

注意

如需以 DTU 為基礎的服務層的詳細資訊,請參閱服務層針對以 DTU 為基礎的購買模型For information about the DTU-based service tiers, see Service tiers for the DTU-based purchasing model. 如需以 DTU 為基礎的服務層和以 vCore 為基礎的購買模型之間的差異資訊,請參閱購買模型的 Azure SQL DatabaseFor information about the differences between the service tiers for the DTU-based and the vCore-based purchasing models, see Azure SQL Database purchasing models.

服務層的特性Service-tier characteristics

以 vCore 為基礎的購買模型提供三種服務層次: 一般用途、 超大規模及業務關鍵。The vCore-based purchasing model provides three service tiers: general purpose, hyperscale, and business critical. 這些服務層是由一連串的計算大小、 高可用性設計、 錯誤隔離方法、 類型和大小的儲存體和 I/O 範圍做區分。These service tiers are differentiated by a range of compute sizes, high-availability designs, fault-isolation methods, types and sizes of storage, and I/O ranges.

您必須個別設定所需的儲存體和備份保留期。You must separately configure the required storage and retention period for backups. 設定備份保留期限,請開啟 Azure 入口網站,請移至伺服器 (不是資料庫),並然後移至管理的備份 > 設定原則 > 點的時間還原組態 > -grs、7-35 天To set the backup-retention period, open the Azure portal, go to the server (not the database), and then go to Manage Backups > Configure Policy > Point In Time Restore Configuration > 7 - 35 days.

下表說明三個層之間的差異:The following table explains the differences between the three tiers:

一般用途General purpose 業務關鍵Business critical HyperscaleHyperscale
適用對象Best for 大部分的商業工作負載。Most business workloads. 供應項目預算為導向、 平衡,且可調整計算和儲存體選項。Offers budget-oriented, balanced, and scalable compute and storage options. 具有高 I/O 需求的商務應用程式。Business applications with high I/O requirements. 使用數個分開的複本,以提供最高的復原失敗。Offers highest resilience to failures by using several isolated replicas. 使用可高度擴充的儲存體和讀取級別需求的大多數商務工作負載。Most business workloads with highly scalable storage and read-scale requirements.
計算Compute 佈建計算:Provisioned compute:
第 4 代:1 到 24 個 v 核心Gen4: 1 to 24 vCores
第 5 代:2 為 80 個 VcoreGen5: 2 to 80 vCores
無伺服器計算:Serverless compute:
第 5 代:0.5-4 個 VcoreGen5: 0.5 - 4 vCores
佈建計算:Provisioned compute:
第 4 代:1 到 24 個 v 核心Gen4: 1 to 24 vCores
第 5 代:2 為 80 個 VcoreGen5: 2 to 80 vCores
佈建計算:Provisioned compute:
第 4 代:1 到 24 個 v 核心Gen4: 1 to 24 vCores
第 5 代:2 為 80 個 VcoreGen5: 2 to 80 vCores
記憶體Memory 佈建計算:Provisioned compute:
第 4 代:每個虛擬核心 7GBGen4: 7 GB per vCore
第 5 代:每個虛擬核心 5.1 GBGen5: 5.1 GB per vCore
無伺服器計算:Serverless compute:
第 5 代:每個虛擬核心 3 GBGen5: 3 GB per vCore
佈建計算:Provisioned compute:
第 4 代:每個虛擬核心 7GBGen4: 7 GB per vCore
第 5 代:每個虛擬核心 5.1 GBGen5: 5.1 GB per vCore
佈建計算:Provisioned compute:
第 4 代:每個虛擬核心 7GBGen4: 7 GB per vCore
第 5 代:每個虛擬核心 5.1 GBGen5: 5.1 GB per vCore
儲存體Storage 使用遠端存放裝置。Uses remote storage.
單一資料庫佈建計算:Single database provisioned compute:
5 GB – 4 TB5 GB – 4 TB
單一資料庫的無伺服器計算:Single database serverless compute:
5 GB - 1 TB5 GB - 1 TB
受控執行個體:32 GB - 8 TBManaged instance: 32 GB - 8 TB
使用本機 SSD 儲存體。Uses local SSD storage.
單一資料庫佈建計算:Single database provisioned compute:
5 GB – 4 TB5 GB – 4 TB
受控執行個體:Managed instance:
32 GB - 4 TB32 GB - 4 TB
所需的儲存體有彈性的自動成長。Flexible autogrow of storage as needed. 支援最多 100 TB 的儲存體。Supports up to 100 TB of storage. 使用本機的緩衝集區快取與本機資料存放區的本機 SSD 儲存體。Uses local SSD storage for local buffer-pool cache and local data storage. 使用 Azure 的遠端儲存體做為最終的長期資料存放區。Uses Azure remote storage as final long-term data store.
I/O 輸送量 (大約)I/O throughput (approximate) 單一資料庫:7000 的最大值 IOPS 與每個虛擬核心 500 IOPS。Single database: 500 IOPS per vCore with 7000 maximum IOPS.
受控執行個體:取決於的檔案大小Managed instance: Depends on size of file.
每個虛擬核心 5000 IOPS,且 IOPS 上限為 200,0005000 IOPS per core with 200,000 maximum IOPS 超大規模是多層式架構與多個層級快取。Hyperscale is a multi-tiered architecture with caching at multiple levels. 有效的 IOPs 將取決於工作負載。Effective IOPs will depend on the workload.
可用性Availability 1 個複本,沒有讀取級別複本1 replica, no read-scale replicas 3 個複本、1 個讀取規模複本3 replicas, 1 read-scale replica,
區域備援的高可用性 (HA)zone-redundant high availability (HA)
1 個讀寫複本,再加上 0 到 4 之間讀取級別複本1 read-write replica, plus 0-4 read-scale replicas
備份Backups 讀取權限異地備援儲存體 (RA-GRS)、-grs、7-35 天 (預設的 7 天)Read-access geo-redundant storage (RA-GRS), 7-35 days (7 days by default) RA-GRS、7-35 天 (預設為 7 天)RA-GRS, 7-35 days (7 days by default) Azure 的遠端儲存體中的快照集式備份。Snapshot-based backups in Azure remote storage. 還原時可使用這些快照集進行快速復原。Restores use these snapshots for fast recovery. 備份是瞬間完成,而且不會影響計算的 I/O 效能。Backups are instantaneous and don't impact compute I/O performance. 還原都很快速,並不是資料大小的作業 (擷取分鐘的時間,而非小時或天)。Restores are fast and aren't a size-of-data operation (taking minutes rather than hours or days).
記憶體內In-memory 不支援Not supported 支援Supported 不支援Not supported

注意

您可以取得免費的 Azure SQL database 搭配使用 Azure 免費帳戶的基本服務層。You can get a free Azure SQL database at the basic service tier in conjunction with an Azure free account. 如需詳細資訊,請參閱 < 使用 Azure 免費帳戶建立受管理的雲端資料庫For more information, see Create a managed cloud database with your Azure free account.

Azure Hybrid BenefitAzure Hybrid Benefit

在佈建的計算層的虛擬核心為基礎的購買模型中,您可以交換您現有的授權,以折扣優惠在 SQL Database 上使用適用於 SQL Server 的 Azure Hybrid BenefitIn the provisioned compute tier of the vCore-based purchasing model, you can exchange your existing licenses for discounted rates on SQL Database by using Azure Hybrid Benefit for SQL Server. 這項 Azure 權益可讓您節省最多 30%的 Azure SQL Database 藉由使用具有軟體保證的內部部署 SQL Server 授權。This Azure benefit allows you to save up to 30 percent on Azure SQL Database by using your on-premises SQL Server licenses with Software Assurance.

定價

使用 Azure Hybrid Benefit,您可以選擇只需支付基礎 Azure 基礎結構的 SQL 資料庫引擎本身 (基底計算定價),使用您現有的 SQL Server 授權,或支付基礎結構和 SQL Server授權 (隨附授權的價格)。With Azure Hybrid Benefit, you can choose to pay only for the underlying Azure infrastructure by using your existing SQL Server license for the SQL database engine itself (Base Compute pricing), or you can pay for both the underlying infrastructure and the SQL Server license (License-Included pricing).

您可以選擇,或變更您的授權模型,使用 Azure 入口網站或使用其中一種下列 Api:You can choose or change your licensing model by using the Azure portal or by using one of the following APIs:

從以 DTU 為基礎的模型移轉至以 vCore 為基礎的模型Migrate from the DTU-based model to the vCore-based model

移轉資料庫Migrate a database

從以 DTU 為基礎的購買模型時使用的資料庫移轉至以 vCore 為基礎的購買模型是類似於升級或降級以 DTU 為基礎的購買模型中的標準和進階服務層之間。Migrating a database from the DTU-based purchasing model to the vCore-based purchasing model is similar to upgrading or downgrading between the standard and premium service tiers in the DTU-based purchasing model.

從以 DTU 為基礎的模型移轉至以 vCore 為基礎的購買模型是類似於升級或降級資料庫中的標準和進階服務層之間的異地複寫關聯性。Migrating from the DTU-based model to the vCore-based purchasing model is similar to upgrading or downgrading the geo-replication relationships between databases in the standard and premium service tiers. 在移轉期間,您不需要停止異地複寫,但您必須遵循這些排序規則:During migration, you don't have to stop geo-replication, but you must follow these sequencing rules:

  • 升級時,您必須先升級次要資料庫,然後再升級主要資料庫。When upgrading, you must upgrade the secondary database first, and then upgrade the primary.
  • 降級時,順序相反︰您必須先降級主要資料庫,然後再降級次要資料庫。When downgrading, reverse the order: you must downgrade the primary database first, and then downgrade the secondary.

當您使用異地複寫兩個彈性集區之間時,我們建議您將一個集區指定為主要和次要資料庫作為其他。When you're using geo-replication between two elastic pools, we recommend that you designate one pool as the primary and the other as the secondary. 在此情況下,當您要移轉的彈性集區時,您應該使用相同的編序指引。In that case, when you're migrating elastic pools you should use the same sequencing guidance. 不過,如果您有包含主要和次要資料庫的彈性集區,視為主要的使用率較高的集區,並據此遵循排序規則。However, if you have elastic pools that contain both primary and secondary databases, treat the pool with the higher utilization as the primary and follow the sequencing rules accordingly.

下表提供特定移轉案例的指引:The following table provides guidance for specific migration scenarios:

目前的服務層級Current service tier 目標服務層級Target service tier 遷移類型Migration type 使用者動作User actions
標準Standard 一般用途General purpose 橫向Lateral 可依任何順序遷移,但必須確保適當的虛擬核心大小調整*Can migrate in any order, but need to ensure appropriate vCore sizing*
進階Premium 業務關鍵Business critical 橫向Lateral 可依任何順序遷移,但必須確保適當的虛擬核心大小調整*Can migrate in any order, but need to ensure appropriate vCore sizing*
標準Standard 業務關鍵Business critical 升級Upgrade 必須先遷移次要Must migrate secondary first
業務關鍵Business critical 標準Standard 降級Downgrade 必須先遷移主要Must migrate primary first
進階Premium 一般用途General purpose 降級Downgrade 必須先遷移主要Must migrate primary first
一般用途General purpose 進階Premium 升級Upgrade 必須先遷移次要Must migrate secondary first
業務關鍵Business critical 一般用途General purpose 降級Downgrade 必須先遷移主要Must migrate primary first
一般用途General purpose 業務關鍵Business critical 升級Upgrade 必須先遷移次要Must migrate secondary first

* 在標準層中每 100 Dtu 需要至少 1 個 vCore,並在進階層中每 125 Dtu 需要至少 1 個 vCore。* Every 100 DTUs in the standard tier require at least 1 vCore, and every 125 DTUs in the premium tier require at least 1 vCore.

遷移容錯移轉群組Migrate failover groups

在遷移具有多個資料庫的容錯移轉群組時,必須個別遷移主要和次要資料庫。Migration of failover groups with multiple databases requires individual migration of the primary and secondary databases. 過程中適用相同的考量和排序規則。During that process, the same considerations and sequencing rules apply. 資料庫會轉換成以虛擬核心為基礎的購買模型之後,容錯移轉群組有效日期會持續使用相同的原則設定。After the databases are converted to the vCore-based purchasing model, the failover group will remain in effect with the same policy settings.

建立異地複寫次要資料庫Create a geo-replication secondary database

您可以建立異地複寫次要資料庫 (異地次要資料庫) 只能藉由使用相同的服務層,與您用於主要資料庫。You can create a geo-replication secondary database (a geo-secondary) only by using the same service tier as you used for the primary database. 具有較高的記錄檔產生速率的資料庫,我們建議使用相同的計算大小,與主要資料庫建立異地次要資料庫。For databases with a high log-generation rate, we recommend creating the geo-secondary with the same compute size as the primary.

如果您要在單一的主要資料庫的彈性集區中建立異地次要資料庫,請確定maxVCore設定集區符合主要資料庫的計算大小。If you're creating a geo-secondary in the elastic pool for a single primary database, make sure the maxVCore setting for the pool matches the primary database's compute size. 如果您要建立異地次要資料庫的主要另一個彈性集區中,我們建議的集區具有相同maxVCore設定。If you're creating a geo-secondary for a primary in another elastic pool, we recommend that the pools have the same maxVCore settings.

若要將以 DTU 為基礎的資料庫轉換成虛擬核心為基礎的資料庫使用資料庫複本Use database copy to convert a DTU-based database to a vCore-based database

您可以將任何資料庫 (具有以 DTU 為基礎的計算大小) 複製到資料庫 (具有以虛擬核心為基礎的計算大小),而不會有任何限制或特殊排序,但前提是目標計算大小支援來源資料庫的最大資料庫大小。You can copy any database with a DTU-based compute size to a database with a vCore-based compute size without restrictions or special sequencing as long as the target compute size supports the maximum database size of the source database. 資料庫複本建立的複製作業的開始時間的資料快照集,並不會同步處理來源與目標之間的資料。The database copy creates a snapshot of the data as of the starting time of the copy operation and doesn't synchronize data between the source and the target.

後續步驟Next steps