在 vCore 服務層級之間選擇, 並從 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個以 Intel E5-2673 v3 (Haswell) 2.4-GHz 處理器為基礎的邏輯 Cpu, vCore = 1 PP (實體核心), 每一核心 7 GB, 連結的 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以 Intel E5-2673 v4 (Broadwell) 2.3-GHz 處理器為基礎的邏輯 Cpu, vCore = 1 LP (超執行緒), 每個核心 5.1 GB, 快速 eNVM SSDGen5: 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.

重要

澳大利亞東部或巴西南部區域不再支援新的第4代資料庫。New Gen4 databases are no longer supported in the Australia East or Brazil South regions.

注意

如需以 DTU 為基礎之服務層的相關資訊, 請參閱以 dtu 為基礎的購買模型的服務層For information about the DTU-based service tiers, see Service tiers for the DTU-based purchasing model. 如需以 DTU 為基礎和以 vCore 為基礎的購買模型之服務層級之間差異的詳細資訊, 請參閱Azure SQL Database 購買模型For 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 入口網站], 移至伺服器 (而不是資料庫), 然後移至 [管理備份 > ] [設定原則 > 時間點還原 > 設定]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 超大規模資料庫Hyperscale
最適用的對象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虛擬核心Gen4: 1 to 24 vCores
第 5 代:2至80虛擬核心Gen5: 2 to 80 vCores
無伺服器計算:Serverless compute:
第 5 代:0.5-4 虛擬核心Gen5: 0.5 - 4 vCores
已布建的計算:Provisioned compute:
第 4 代:1到24虛擬核心Gen4: 1 to 24 vCores
第 5 代:2至80虛擬核心Gen5: 2 to 80 vCores
已布建的計算:Provisioned compute:
第 4 代:1到24虛擬核心Gen4: 1 to 24 vCores
第 5 代:2至80虛擬核心Gen5: 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) 單一資料庫:500 IOPS (每個 vCore 具有7000的最大 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), 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 資料庫, 並搭配 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

在 vCore 為基礎的購買模型的已布建計算層中, 您可以使用SQL Server 的 Azure Hybrid Benefit, 在 SQL Database 上交換您現有的授權以享有折扣優惠。In 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 權益可讓您使用內部部署 SQL Server 授權搭配軟體保證, 最多省下 30% 的 Azure SQL Database。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, 您可以選擇只使用現有的 SQL database engine SQL Server 授權 (基礎計算定價) 來支付基礎 Azure 基礎結構的費用, 也可以為基礎結構和 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 為基礎的購買模型中的 standard 和 premium 服務層級之間的升級或降級。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 為基礎的購買模型, 類似于在 standard 和 premium 服務層級中的資料庫之間升級或降級異地複寫關聯性。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. 將資料庫轉換成 vCore 為基礎的購買模型之後, 容錯移轉群組將會使用相同的原則設定繼續作用。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 為基礎的資料庫轉換成以 vCore 為基礎的資料庫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