Scegliere tra i livelli di servizio vCore ed eseguire la migrazione dai livelli di servizio DTUChoose among the vCore service tiers and migrate from the DTU service tiers

La memoria centrale virtuale (vCore)-modello di acquisto basato su consente di ridimensionare le risorse di calcolo e archiviazione in modo indipendente, corrispondono prestazioni locali e ottimizzare i costi.The virtual core (vCore)-based purchasing model lets you independently scale compute and storage resources, match on-premises performance, and optimize price. Consente inoltre di scegliere la generazione di hardware:It also lets you choose the generation of hardware:

  • Gen4: Fino a 24 CPU logiche basati su Intel E5-2673 v3 processori 2,4 GHz (Haswell), vCore = 1 PP (core fisici), 7 GB per core, collegato a unità 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
  • Gen5: Fino a 80 CPU logiche basati su Intel E5-2673 v4 processori 2,3 GHz (Broadwell), vCore = 1 LP (hyper-thread), 5.1 GB per core, eNVM veloce 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

L'hardware Gen4 offre molta più memoria per ogni vCore.Gen4 hardware offers substantially more memory per vCore. L'hardware Gen5 consente tuttavia di aumentare molto di più le risorse di calcolo.However, Gen5 hardware allows you to scale up compute resources much higher.

Nota

Per informazioni sui livelli di servizio basato su DTU, vedere livelli per il modello di acquisto basato su DTU di servizio.For information about the DTU-based service tiers, see Service tiers for the DTU-based purchasing model. Per informazioni sulle differenze tra i livelli di servizio per il basato su DTU e i modelli di acquisto basato su vCore, vedere Database SQL di Azure i modelli di acquisto.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.

Caratteristiche di livello di servizioService-tier characteristics

Il modello di acquisto basato su vCore offre tre livelli di servizio: generico e con scalabilità elevatissima aziendale critica.The vCore-based purchasing model provides three service tiers: general purpose, hyperscale, and business critical. Questi livelli di servizio si differenziano per un intervallo di dimensioni di calcolo, le progettazioni a disponibilità elevata, isolamento degli errori metodi, tipi e dimensioni di archiviazione e gli intervalli dei / 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.

È necessario configurare separatamente le risorse di archiviazione e il periodo di conservazione richiesti per i backup.You must separately configure the required storage and retention period for backups. Per impostare il periodo di conservazione dei backup, aprire il portale di Azure, passare al server (non il database) e quindi andare al Manage Backups > configurare un criterio > Punto In fase di ripristino della configurazione > 7 a 35 giorni.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.

Nella tabella seguente vengono illustrate le differenze tra i tre livelli:The following table explains the differences between the three tiers:

Utilizzo genericoGeneral purpose Aziendale criticaBusiness critical Su scala molto vastaHyperscale
Ideale perBest for La maggior parte dei carichi di lavoro aziendali.Most business workloads. Calcolo orientate al budget, bilanciata e ridimensionabili offerte e opzioni di archiviazione.Offers budget-oriented, balanced, and scalable compute and storage options. Applicazioni aziendali con requisiti elevati dei / o.Business applications with high I/O requirements. Offre massima resilienza agli errori tramite diverse repliche isolate.Offers highest resilience to failures by using several isolated replicas. La maggior parte delle business i carichi di lavoro con requisiti di scalabilità in lettura e un'archiviazione altamente scalabile.Most business workloads with highly scalable storage and read-scale requirements.
CalcoloCompute Il provisioning di calcolo:Provisioned compute:
Quarta generazione: numero di Vcore da 1 a 24Gen4: 1 to 24 vCores
Quinta generazione: numero di Vcore da 2 a 80Gen5: 2 to 80 vCores
Calcolo senza server:Serverless compute:
Quinta generazione: 0,5 - 4 Vcore per utilizzoGen5: 0.5 - 4 vCores
Il provisioning di calcolo:Provisioned compute:
Quarta generazione: numero di Vcore da 1 a 24Gen4: 1 to 24 vCores
Quinta generazione: numero di Vcore da 2 a 80Gen5: 2 to 80 vCores
Il provisioning di calcolo:Provisioned compute:
Quarta generazione: numero di Vcore da 1 a 24Gen4: 1 to 24 vCores
Quinta generazione: numero di Vcore da 2 a 80Gen5: 2 to 80 vCores
MemoriaMemory Il provisioning di calcolo:Provisioned compute:
Quarta generazione: 7 GB per vCoreGen4: 7 GB per vCore
Quinta generazione: 5,1 GB per vCoreGen5: 5.1 GB per vCore
Calcolo senza server:Serverless compute:
Quinta generazione: 3 GB per vCoreGen5: 3 GB per vCore
Il provisioning di calcolo:Provisioned compute:
Quarta generazione: 7 GB per vCoreGen4: 7 GB per vCore
Quinta generazione: 5,1 GB per vCoreGen5: 5.1 GB per vCore
Il provisioning di calcolo:Provisioned compute:
Quarta generazione: 7 GB per vCoreGen4: 7 GB per vCore
Quinta generazione: 5,1 GB per vCoreGen5: 5.1 GB per vCore
ArchiviazioneStorage Usa l'archiviazione remota.Uses remote storage.
Il provisioning di database singolo calcolo:Single database provisioned compute:
5 GB - 4 TB5 GB – 4 TB
Calcolo senza server di database singolo:Single database serverless compute:
5 GB - 1 TB5 GB - 1 TB
Istanza gestita: 32 GB - 8 TBManaged instance: 32 GB - 8 TB
Usa l'archiviazione SSD locale.Uses local SSD storage.
Il provisioning di database singolo calcolo:Single database provisioned compute:
5 GB - 4 TB5 GB – 4 TB
Istanza gestita:Managed instance:
32 GB - 4 TB32 GB - 4 TB
Aumento automatico flessibile di archiviazione in base alle esigenze.Flexible autogrow of storage as needed. Supporta fino a 100 TB di spazio di archiviazione.Supports up to 100 TB of storage. Usa l'archiviazione SSD locale per la cache del pool di buffer locale e archiviazione locale dei dati.Uses local SSD storage for local buffer-pool cache and local data storage. Usa l'archiviazione remota Azure come archivio di dati a lungo termine finale.Uses Azure remote storage as final long-term data store.
Velocità effettiva dei / o (approssimativa)I/O throughput (approximate) Database singolo: 500 IOPS per ogni vCore con numero massimo di 7000 IOPS.Single database: 500 IOPS per vCore with 7000 maximum IOPS.
Istanza gestita: Dipende alle dimensioni dei file.Managed instance: Depends on size of file.
5000 operazioni di I/O al secondo per core fino a un massimo di 200.0005000 IOPS per core with 200,000 maximum IOPS Su scala molto vasta è un'architettura a più livelli con più livelli di memorizzazione nella cache.Hyperscale is a multi-tiered architecture with caching at multiple levels. IOPs effettivo varia in base al carico di lavoro.Effective IOPs will depend on the workload.
DisponibilitàAvailability 1 replica, le repliche non scalabilità in lettura1 replica, no read-scale replicas 3 repliche, 1 replica scalabilità in lettura,3 replicas, 1 read-scale replica,
con ridondanza della zona di disponibilità elevata (HA)zone-redundant high availability (HA)
1 replica di lettura / scrittura, oltre a 0 e 4 repliche con scalabilità in lettura1 read-write replica, plus 0-4 read-scale replicas
BackupBackups Archiviazione con ridondanza geografica e accesso in lettura (RA-GRS)7 a 35 giorni (7 giorni per impostazione predefinita),Read-access geo-redundant storage (RA-GRS), 7-35 days (7 days by default) RA-GRS, da 7 a 35 giorni (7 giorni per impostazione predefinita)RA-GRS, 7-35 days (7 days by default) Basato su snapshot di backup nella risorsa di archiviazione Azure remoto.Snapshot-based backups in Azure remote storage. Questi snapshot vengono usati per il ripristino rapido.Restores use these snapshots for fast recovery. I backup vengono visualizzati immediatamente e non compromettere le prestazioni dei / o di calcolo.Backups are instantaneous and don't impact compute I/O performance. I ripristini sono veloci e non sono un'operazione di dimensioni dei dati (prendendo minuti anziché ore o giorni).Restores are fast and aren't a size-of-data operation (taking minutes rather than hours or days).
In memoriaIn-memory Non supportateNot supported SupportatoSupported Non supportateNot supported

Nota

È possibile ottenere un database SQL di Azure disponibile a livello di servizio di base in combinazione con un account Azure gratuito.You can get a free Azure SQL database at the basic service tier in conjunction with an Azure free account. Per altre informazioni, vedere creare un database cloud gestito con il tuo account gratuito Azure.For more information, see Create a managed cloud database with your Azure free account.

Vantaggio Azure HybridAzure Hybrid Benefit

Nel livello di calcolo sottoposte a provisioning del modello di acquisto basato su vCore, è possibile scambiare le licenze esistenti con tariffe scontate su Database SQL per usando vantaggio Azure Hybrid per SQL Server.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. Questo vantaggio di Azure consente di risparmiare fino al 30% sul Database SQL di Azure usando le tue licenze di SQL Server locali con Software Assurance.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.

prezzi

Con vantaggio Azure Hybrid, è possibile scegliere di pagare solo per l'infrastruttura di Azure sottostante utilizzando la licenza di SQL Server esistente per il motore di database SQL (prezzi di calcolo di Base), oppure è possibile pagare per l'infrastruttura sottostante e SQL Server licenze (licenza inclusa di prezzo).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).

È possibile scegliere o modificare il modello di licenza tramite il portale di Azure o usando una delle seguenti API:You can choose or change your licensing model by using the Azure portal or by using one of the following APIs:

Eseguire la migrazione dal modello basato su DTU per il modello basato su vCoreMigrate from the DTU-based model to the vCore-based model

Eseguire la migrazione di un databaseMigrate a database

La migrazione di un database dal modello di acquisto basato su DTU per il modello di acquisto basato su vCore è simile all'aggiornamento o downgrade tra i livelli di servizio standard e premium nel modello di acquisto basato su 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.

La migrazione dal modello basato su DTU per il modello di acquisto basato su vCore è simile all'aggiornamento o downgrade le relazioni di replica geografica tra i database nei livelli di servizio standard e 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. Durante la migrazione, non è necessario arrestare la replica geografica, ma devono rispettare queste regole di sequenziazione:During migration, you don't have to stop geo-replication, but you must follow these sequencing rules:

  • Quando si esegue l'aggiornamento, è necessario aggiornare prima il database secondario e dopo il database primario.When upgrading, you must upgrade the secondary database first, and then upgrade the primary.
  • Quando si esegue il downgrade, è necessario seguire l'ordine inverso, ovvero eseguire prima il downgrade del database primario e dopo quello del database secondario.When downgrading, reverse the order: you must downgrade the primary database first, and then downgrade the secondary.

Quando si usa la replica geografica tra due pool elastici, è consigliabile che designarne uno come primario e l'altro come secondario.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 tal caso, quando si esegue la migrazione di pool elastici è consigliabile usare le stesse linee guida di sequenziazione.In that case, when you're migrating elastic pools you should use the same sequencing guidance. Tuttavia, se si dispone di pool elastici che contengono database primari e secondari, trattare il pool con l'utilizzo più elevato del database primario e seguire le regole di sequenziazione di conseguenza.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.

Nella tabella seguente fornisce indicazioni per specifici scenari di migrazione:The following table provides guidance for specific migration scenarios:

Livello di servizio correnteCurrent service tier Livello di servizio di destinazioneTarget service tier Tipo di migrazioneMigration type Azioni utenteUser actions
StandardStandard Scopo genericoGeneral purpose LateraleLateral L'ordine di migrazione non è rilevante, ma è necessario verificare che il numero di vCore sia appropriato*Can migrate in any order, but need to ensure appropriate vCore sizing*
PremiumPremium Business CriticalBusiness critical LateraleLateral L'ordine di migrazione non è rilevante, ma è necessario verificare che il numero di vCore sia appropriato*Can migrate in any order, but need to ensure appropriate vCore sizing*
StandardStandard Business CriticalBusiness critical AggiornamentoUpgrade È necessario eseguire prima la migrazione del database secondarioMust migrate secondary first
Business CriticalBusiness critical StandardStandard DowngradeDowngrade È necessario eseguire prima la migrazione del database primarioMust migrate primary first
PremiumPremium Scopo genericoGeneral purpose DowngradeDowngrade È necessario eseguire prima la migrazione del database primarioMust migrate primary first
Scopo genericoGeneral purpose PremiumPremium AggiornamentoUpgrade È necessario eseguire prima la migrazione del database secondarioMust migrate secondary first
Business CriticalBusiness critical Scopo genericoGeneral purpose DowngradeDowngrade È necessario eseguire prima la migrazione del database primarioMust migrate primary first
Scopo genericoGeneral purpose Business CriticalBusiness critical AggiornamentoUpgrade È necessario eseguire prima la migrazione del database secondarioMust migrate secondary first

* Ogni 100 Dtu nel livello standard richiede almeno 1 vCore e ogni 125 Dtu nel livello premium richiede almeno 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.

Eseguire la migrazione di gruppi di failoverMigrate failover groups

Per i gruppi di failover con più database è necessario eseguire separatamente la migrazione dei database primari e secondari.Migration of failover groups with multiple databases requires individual migration of the primary and secondary databases. Durante questo processo sono valide le stesse considerazioni e regole di sequenziazione.During that process, the same considerations and sequencing rules apply. Dopo la conversione dei database per il modello di acquisto basato su vCore, il gruppo di failover rimarranno in vigore con le stesse impostazioni di criteri.After the databases are converted to the vCore-based purchasing model, the failover group will remain in effect with the same policy settings.

Creare un database secondario con replica geograficaCreate a geo-replication secondary database

È possibile creare un database secondario con replica geografica (geo-secondary) solo usando lo stesso livello di servizio perché è usato per il database primario.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. Per i database con una frequenza elevata di generazione log, è consigliabile creare la replica geografica secondaria con le stesse dimensioni di calcolo del database primario.For databases with a high log-generation rate, we recommend creating the geo-secondary with the same compute size as the primary.

Se si crea una replica geografica secondaria nel pool elastico per un singolo database primario, assicurarsi che il maxVCore impostazione per il pool corrisponde alla dimensione di calcolo del database primario.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. Se si crea una replica geografica secondaria per un database primario in un altro pool elastico, è consigliabile che i pool hanno gli stessi maxVCore impostazioni.If you're creating a geo-secondary for a primary in another elastic pool, we recommend that the pools have the same maxVCore settings.

Usare copia del database per convertire un database basato su DTU a un database basato su vCoreUse database copy to convert a DTU-based database to a vCore-based database

È possibile copiare un database con dimensioni di calcolo basate su DTU in un database con dimensioni di calcolo basate su vCore senza restrizioni o particolari regole di sequenziazione a condizione che le dimensioni di calcolo del database di destinazione supportino le dimensioni massime del database di origine.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. La copia del database crea uno snapshot dei dati a partire da ora di inizio dell'operazione di copia e non sincronizza dati tra l'origine e destinazione.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.

Passaggi successiviNext steps