Eseguire la migrazione del database Azure SQL dal modello basato su DTU al modello basato su vCore

Si applica a: Database SQL di Azure

Questo articolo descrive come eseguire la migrazione del database in Azure SQL Database dal modello di acquisto basato su DTU al modello di acquisto basato suvCore.

Eseguire la migrazione di un database

La migrazione di un database dal modello di acquisto basato su DTU al modello di acquisto basato su vCore è simile al ridimensionamento tra gli obiettivi del servizio nei livelli di servizio Basic, Standard e Premium, con durata simile e un tempo di inattività minimo alla fine del processo di migrazione. È possibile eseguire la migrazione di un database al modello di acquisto basato su vCore al modello di acquisto basato su DTU in qualsiasi momento, ad eccezione dei database migrati al livello di servizio Hyperscale .

Scegliere il livello di servizio vCore e l'obiettivo del servizio

Per la maggior parte degli scenari di migrazione VCore, i database e i pool elastici nei livelli di servizio Basic e Standard verranno mappati al livello di servizio per utilizzo generico. I database e i pool elastici nel livello di servizio Premium verranno mappati al livello di servizio business critical. A seconda dello scenario e dei requisiti dell'applicazione, il livello di servizio Hyperscale può spesso essere usato come destinazione di migrazione per i singoli database in tutti i livelli di servizio DTU.

Per scegliere l'obiettivo del servizio o le dimensioni di calcolo, per il database migrato nel modello vCore, è possibile usare una regola semplice ma approssimativa: ogni 100 DTU nei livelli Basic o Standard richiede almeno 1 vCore e ogni 125 DTU nel livello Premium richiede almeno 1 vCore.

Suggerimento

Questa regola è approssimativa perché non considera il tipo specifico di hardware usato per il database DTU o il pool elastico.

Nel modello DTU il sistema può selezionare qualsiasi configurazione hardware disponibile per il database o il pool elastico. Inoltre, nel modello DTU si ha solo il controllo indiretto sul numero di CPU vCore (logici CPU) scegliendo valori DTU superiori o inferiori o eDTU.

Nel modello vCore i clienti devono scegliere esplicitamente sia la configurazione hardware che il numero di cpu vCore (CPU logiche). Anche se il modello DTU non offre queste opzioni, il tipo di hardware e il numero di CPU logiche usate per ogni database e pool elastico vengono esposti tramite viste di gestione dinamica. In questo modo è possibile determinare più precisamente l'obiettivo del servizio vCore corrispondente.

L'approccio seguente usa queste informazioni per determinare un obiettivo del servizio vCore con un'allocazione simile delle risorse, per ottenere un livello simile di prestazioni dopo la migrazione al modello vCore.

Mapping DTU a vCore

Una query T-SQL riportata di seguito, quando viene eseguita nel contesto di un database DTU da eseguire la migrazione, restituisce un numero corrispondente (possibilmente frazionato) di vCore in ogni configurazione hardware nel modello vCore. Arrotondando questo numero al numero più vicino di vCore disponibili per i database e i pool elastici in ogni configurazione hardware nel modello vCore, i clienti possono scegliere l'obiettivo del servizio vCore più vicino per il database DTU o il pool elastico.

Gli scenari di migrazione di esempio che usano questo approccio sono descritti nella sezione Esempi .

Eseguire questa query nel contesto del database da eseguire per la migrazione, anziché nel master database. Quando si esegue la migrazione di un pool elastico, eseguire la query nel contesto di qualsiasi database nel pool.

WITH dtu_vcore_map AS
(
SELECT rg.slo_name,
       CAST(DATABASEPROPERTYEX(DB_NAME(), 'Edition') AS nvarchar(40)) COLLATE DATABASE_DEFAULT AS dtu_service_tier,
       CASE WHEN slo.slo_name LIKE '%SQLG4%' THEN 'Gen4'
            WHEN slo.slo_name LIKE '%SQLGZ%' THEN 'Gen4'
            WHEN slo.slo_name LIKE '%SQLG5%' THEN 'Gen5'
            WHEN slo.slo_name LIKE '%SQLG6%' THEN 'Gen5'
            WHEN slo.slo_name LIKE '%SQLG7%' THEN 'Gen5'
            WHEN slo.slo_name LIKE '%GPGEN8%' THEN 'Gen5'
       END COLLATE DATABASE_DEFAULT AS dtu_hardware_gen,
       s.scheduler_count * CAST(rg.instance_cap_cpu/100. AS decimal(3,2)) AS dtu_logical_cpus,
       CAST((jo.process_memory_limit_mb / s.scheduler_count) / 1024. AS decimal(4,2)) AS dtu_memory_per_core_gb
FROM sys.dm_user_db_resource_governance AS rg
CROSS JOIN (SELECT COUNT(1) AS scheduler_count FROM sys.dm_os_schedulers WHERE status COLLATE DATABASE_DEFAULT = 'VISIBLE ONLINE') AS s
CROSS JOIN sys.dm_os_job_object AS jo
CROSS APPLY (
            SELECT UPPER(rg.slo_name) COLLATE DATABASE_DEFAULT AS slo_name
            ) slo
WHERE rg.dtu_limit > 0
      AND
      DB_NAME() COLLATE DATABASE_DEFAULT <> 'master'
      AND
      rg.database_id = DB_ID()
)
SELECT dtu_logical_cpus,
       dtu_hardware_gen,
       dtu_memory_per_core_gb,
       dtu_service_tier,
       CASE WHEN dtu_service_tier = 'Basic' THEN 'General Purpose'
            WHEN dtu_service_tier = 'Standard' THEN 'General Purpose or Hyperscale'
            WHEN dtu_service_tier = 'Premium' THEN 'Business Critical or Hyperscale'
       END AS vcore_service_tier,
       CASE WHEN dtu_hardware_gen = 'Gen4' THEN dtu_logical_cpus
            WHEN dtu_hardware_gen = 'Gen5' THEN dtu_logical_cpus * 0.7
       END AS Gen4_vcores,
       7 AS Gen4_memory_per_core_gb,
       CASE WHEN dtu_hardware_gen = 'Gen4' THEN dtu_logical_cpus * 1.7
            WHEN dtu_hardware_gen = 'Gen5' THEN dtu_logical_cpus
       END AS Gen5_vcores,
       5.05 AS Gen5_memory_per_core_gb,
       CASE WHEN dtu_hardware_gen = 'Gen4' THEN dtu_logical_cpus
            WHEN dtu_hardware_gen = 'Gen5' THEN dtu_logical_cpus * 0.8
       END AS Fsv2_vcores,
       1.89 AS Fsv2_memory_per_core_gb,
       CASE WHEN dtu_hardware_gen = 'Gen5' THEN dtu_logical_cpus * 0.7
             WHEN dtu_hardware_gen = 'Gen4' THEN dtu_logical_cpus
       END AS DC_vcores,
       4.5 AS DC_memory_per_core_gb
FROM dtu_vcore_map;

Fattori aggiuntivi

Oltre al numero di cpu vCore (cpu logiche) e al tipo di hardware, diversi altri fattori possono influire sulla scelta dell'obiettivo del servizio vCore:

  • La query Transact-SQL di mapping corrisponde agli obiettivi del servizio DTU e vCore in termini di capacità della CPU, pertanto i risultati saranno più accurati per i carichi di lavoro associati alla CPU.
  • Per lo stesso tipo di hardware e lo stesso numero di vCore, operazioni di I/O al secondo e limiti delle risorse di velocità effettiva del log delle transazioni per i database vCore sono spesso superiori rispetto ai database DTU. Per i carichi di lavoro associati a IO, potrebbe essere possibile ridurre il numero di vCore nel modello vCore per ottenere lo stesso livello di prestazioni. I limiti effettivi delle risorse per i database DTU e vCore vengono esposti nella visualizzazione sys.dm_user_db_resource_governance . Confronto di questi valori tra il database o il pool DTU da eseguire la migrazione e un database vCore o un pool con un obiettivo di servizio corrispondente approssimativamente consente di selezionare l'obiettivo del servizio vCore più precisamente.
  • La query di mapping restituisce anche la quantità di memoria per core per il database DTU o il pool elastico da eseguire la migrazione e per ogni configurazione hardware nel modello vCore. Garantire una memoria totale simile o superiore dopo la migrazione a vCore è importante per i carichi di lavoro che richiedono una cache di dati di memoria di grandi dimensioni per ottenere prestazioni sufficienti o carichi di lavoro che richiedono concessioni di memoria di grandi dimensioni per l'elaborazione di query. Per tali carichi di lavoro, a seconda delle prestazioni effettive, potrebbe essere necessario aumentare il numero di vCore per ottenere una memoria totale sufficiente.
  • L'utilizzo cronologico delle risorse del database DTU deve essere considerato quando si sceglie l'obiettivo del servizio vCore. I database DTU con risorse CPU usate in modo coerente potrebbero richiedere meno vCore rispetto al numero restituito dalla query di mapping. Al contrario, i database DTU in cui l'utilizzo della CPU costantemente elevato causa prestazioni del carico di lavoro inadeguate possono richiedere più vCore rispetto a quelli restituiti dalla query.
  • Se si esegue la migrazione di database con modelli di utilizzo intermittenti o imprevedibili, considerare l'uso del livello di calcolo serverless . Si noti che il numero massimo di lavoratori simultanei nel serverless è il 75% del limite nel calcolo con provisioning per lo stesso numero di vCore max configurati. Inoltre, la memoria massima disponibile in serverless è di 3 GB il numero massimo di vCore configurati, che è minore della memoria per core per il provisioning. Ad esempio, in Gen5 max memory è 120 GB quando sono configurati 40 max vCore in serverless e 204 GB per un calcolo con provisioning vCore 40.
  • Nel modello vCore le dimensioni massime supportate possono variare a seconda dell'hardware. Per i database di grandi dimensioni, controllare le dimensioni massime supportate nel modello vCore per database singoli e pool elastici.
  • Per i pool elastici, i modelli DTU e vCore presentano differenze nel numero massimo di database supportati per pool. Ciò deve essere considerato quando si esegue la migrazione di pool elastici con molti database.
  • Alcune configurazioni hardware potrebbero non essere disponibili in ogni area. Controllare la disponibilità in Configurazione hardware per database SQL.

Importante

Le linee guida di ridimensionamento di DTU a vCore riportate sopra sono fornite per facilitare la stima iniziale dell'obiettivo del servizio di database di destinazione.

La configurazione ottimale del database di destinazione dipende dal carico di lavoro. Pertanto, per ottenere il rapporto prezzo/prestazioni ottimale dopo la migrazione, potrebbe essere necessario sfruttare la flessibilità del modello vCore per modificare il numero di vCore, configurazione hardware e livelli di calcolo e servizio. Potrebbe anche essere necessario modificare i parametri di configurazione del database, ad esempio il grado massimo di parallelismo e/o modificare il livello di compatibilità del database per abilitare i miglioramenti recenti nel motore di database.

Esempi di migrazione DTU a vCore

Nota

I valori negli esempi seguenti sono solo a scopo di illustrazione. I valori effettivi restituiti negli scenari descritti possono essere diversi.

Migrazione di un database S9 Standard

La query di mapping restituisce il risultato seguente (alcune colonne non visualizzate per brevità):

dtu_logical_cpus dtu_hardware_gen dtu_memory_per_core_gb Gen4_vcores Gen4_memory_per_core_gb Gen5_vcores Gen5_memory_per_core_gb
24.00 Quinta generazione 5.40 16.800 7 24.000 5.05

Si noterà che il database DTU ha 24 CPU logiche (vCore), con 5,4 GB di memoria per vCore e usa hardware Gen5. La corrispondenza diretta a questa è un database per utilizzo generico 24 vCore nell'hardware Gen5, ad esempio l'obiettivo del servizio vCore GP_Gen5_24.

Migrazione di un database S0 Standard

La query di mapping restituisce il risultato seguente (alcune colonne non visualizzate per brevità):

dtu_logical_cpus dtu_hardware_gen dtu_memory_per_core_gb Gen4_vcores Gen4_memory_per_core_gb Gen5_vcores Gen5_memory_per_core_gb
0,25 Quarta generazione 0.42 0.250 7 0.425 5.05

Si noterà che il database DTU ha l'equivalente di 0,25 CPU logiche (vCore), con 0,42 GB di memoria per vCore e usa hardware Gen4. Gli obiettivi di servizio vCore più piccoli nelle configurazioni hardware Gen4 e Gen5, GP_Gen4_1 e GP_Gen5_2, forniscono più risorse di calcolo rispetto al database S0 Standard, quindi non è possibile una corrispondenza diretta. Poiché l'hardware Gen4 viene rimosso, l'opzione GP_Gen5_2 è preferibile. Inoltre, se il carico di lavoro è adatto per il livello di calcolo serverless , GP_S_Gen5_1 sarebbe una corrispondenza più vicina.

Migrazione di un database Premium P15

La query di mapping restituisce il risultato seguente (alcune colonne non visualizzate per brevità):

dtu_logical_cpus dtu_hardware_gen dtu_memory_per_core_gb Gen4_vcores Gen4_memory_per_core_gb Gen5_vcores Gen5_memory_per_core_gb
42.00 Quinta generazione 4.86 29.400 7 42.000 5.05

Si noterà che il database DTU ha 42 CPU logiche (vCore), con 4,86 GB di memoria per vCore e usa hardware Gen5. Anche se non esiste un obiettivo di servizio vCore con 42 core, l'obiettivo del servizio BC_Gen5_40 è molto vicino in termini di CPU e capacità di memoria ed è una buona corrispondenza.

Migrazione di un pool elastico eDTU Basic 200

La query di mapping restituisce il risultato seguente (alcune colonne non visualizzate per brevità):

dtu_logical_cpus dtu_hardware_gen dtu_memory_per_core_gb Gen4_vcores Gen4_memory_per_core_gb Gen5_vcores Gen5_memory_per_core_gb
4,00 Quinta generazione 5.40 2.800 7 4.000 5.05

Si noterà che il pool elastico DTU ha 4 CPU logiche (vCore), con 5,4 GB di memoria per vCore e usa l'hardware Gen5. La corrispondenza diretta nel modello vCore è un pool elastico GP_Gen5_4 . Tuttavia, questo obiettivo di servizio supporta un massimo di 200 database per pool, mentre il pool elastico Basic 200 eDTU supporta fino a 500 database. Se la migrazione del pool elastico ha più di 200 database, l'obiettivo del servizio vCore corrispondente deve essere GP_Gen5_6, che supporta fino a 500 database.

Eseguire la migrazione di database con replica geografica

La migrazione dal modello basato su DTU al modello di acquisto basato su vCore è simile all'aggiornamento o al downgrade delle relazioni di replica geografica tra i database nei livelli di servizio Standard e Premium. Durante la migrazione non è necessario arrestare la replica geografica, ma è necessario seguire queste regole di sequenziazione:

  • Quando si esegue l'aggiornamento, è necessario aggiornare prima il database secondario e dopo il database primario.
  • Quando si esegue il downgrade, è necessario seguire l'ordine inverso, ovvero eseguire prima il downgrade del database primario e dopo quello del database secondario.

Quando si usa la replica geografica tra due pool elastici, è consigliabile designare un pool come primario e l'altro come secondario. In tal caso, quando si esegue la migrazione di pool elastici, è consigliabile usare le stesse linee guida per la sequenziazione. Tuttavia, se si dispone di pool elastici che contengono database primari e secondari, considerare il pool con un utilizzo maggiore come primario e seguire di conseguenza le regole di sequenziazione.

La tabella seguente fornisce indicazioni per scenari di migrazione specifici:

Livello di servizio corrente Livello di servizio di destinazione Tipo di migrazione Azioni utente
Standard Scopo generico Laterale Può eseguire la migrazione in qualsiasi ordine, ma è necessario garantire il dimensionamento vCore appropriato, come descritto in precedenza
Premium Business Critical Laterale Può eseguire la migrazione in qualsiasi ordine, ma è necessario garantire il dimensionamento vCore appropriato, come descritto in precedenza
Standard Business Critical Aggiornamento È necessario eseguire prima la migrazione del database secondario
Business Critical Standard Downgrade È necessario eseguire prima la migrazione del database primario
Premium Scopo generico Downgrade È necessario eseguire prima la migrazione del database primario
Scopo generico Premium Aggiornamento È necessario eseguire prima la migrazione del database secondario
Business Critical Scopo generico Downgrade È necessario eseguire prima la migrazione del database primario
Scopo generico Business Critical Aggiornamento È necessario eseguire prima la migrazione del database secondario

Eseguire la migrazione dei gruppi di failover

Per i gruppi di failover con più database è necessario eseguire separatamente la migrazione dei database primari e secondari. Durante questo processo sono valide le stesse considerazioni e regole di sequenziazione. Dopo la conversione dei database nel modello di acquisto basato su vCore, il gruppo di failover rimarrà attivo con le stesse impostazioni dei criteri.

Creare un database secondario di replica geografica

È possibile creare un database secondario di replica geografica (un database geografico secondario) solo usando lo stesso livello di servizio usato per il database primario. Per i database con una frequenza di generazione log elevata, è consigliabile creare la replica geografica secondaria con le stesse dimensioni di calcolo del database primario.

Se si crea un database secondario geografico nel pool elastico per un singolo database primario, assicurarsi che l'impostazione maxVCore per il pool corrisponda alle dimensioni di calcolo del database primario. Se si crea un database secondario geografico per un database primario in un altro pool elastico, è consigliabile che i pool abbiano le stesse maxVCore impostazioni.

Usare la copia del database per eseguire la migrazione da DTU a vCore

È 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. La copia del database crea uno snapshot coerente a livello di transazione dei dati a partire da un punto nel tempo dopo l'avvio dell'operazione di copia. Non sincronizza i dati tra l'origine e la destinazione dopo tale punto nel tempo.

Passaggi successivi