Az Azure SQL Database migrálása a DTU-alapú modellből a virtuális magalapú modellbe

A következőkre vonatkozik:Azure SQL Database

Ez a cikk azt ismerteti, hogyan migrálhatja az Azure SQL Database adatbázisát a DTU-alapú vásárlási modellből a vCore-alapú vásárlási modellbe.

Adatbázis migrálása

Az adatbázis DTU-alapú vásárlási modellből virtuális magalapú vásárlási modellbe való migrálása hasonló az alapszintű, standard és prémium szolgáltatási szintek szolgáltatási célkitűzéseinek skálázásához, hasonló időtartamú és minimális állásidővel a migrálási folyamat végén. A vCore-alapú vásárlási modellbe migrált adatbázisok bármikor visszatelepíthetők a DTU-alapú vásárlási modellbe ugyanazokkal a lépésekkel, kivéve a Hyperscale szolgáltatási szintre migrált adatbázisokat.

Az adatbázist egy másik vásárlási modellbe migrálhatja az Azure Portal, a PowerShell, az Azure CLI és a Transact-SQL használatával.

$parameters = @{
     ResourceGroupName = "<resource group name>"
     DatabaseName = "<database name>"
     ServerName = "<server name>"
     Edition = "<service tier, such as Hyperscale>"
     RequestedServiceObjectiveName = "<hardware such as HS_Gen5_2>"
}

Set-AzSqlDatabase @parameters

az sql db update --resource-group "<resource group name>" --server "<server name>" --name "<database name>" --edition <service tier, such as Hyperscale> --capacity 4 --family Gen5

ALTER DATABASE <database name> MODIFY (EDITION = '<service tier, such as Hyperscale>');

Válassza ki a virtuális mag szolgáltatásszintet és a szolgáltatási célkitűzést

A legtöbb DTU-ról virtuális magra történő migrálási forgatókönyv esetében az alapszintű és standard szolgáltatási szintekhez tartozó adatbázisok és rugalmas készletek az Általános célú szolgáltatási szintre lesznek leképezve. A Prémium szolgáltatási szint adatbázisai és rugalmas csoportjai az üzletileg kritikus szolgáltatási szintnek felelnek meg. Az alkalmazás forgatókönyvétől és követelményeitől függően a rugalmas skálázású szolgáltatási szint gyakran használható migrálási célként az adatbázisok és rugalmas készletek esetében az összes DTU szolgáltatásszinten.

A vCore modellbe migrált adatbázis szolgáltatási célkitűzésének vagy számítási méretének kiválasztásához használhat egy egyszerű hüvelykujjszabályt: az alapszintű vagy standard szinten minden 100 DTU-hoz legalább 1 vCore szükséges, és a Prémium szinten minden 125 DTU -hoz legalább 1 vCore szükséges.

A DTU-modellben a rendszer bármely elérhető hardverkonfigurációt kiválaszthatja az adatbázisához vagy a rugalmas készletéhez. Emellett a DTU-modellben csak közvetett módon szabályozhatja a virtuális magok (logikai CPU-k) számát, ha magasabb vagy alacsonyabb DTU- vagy eDTU-értékeket választ.

A virtuális mag modellben az ügyfeleknek explicit módon kell választaniuk mind a hardverkonfigurációt, mind a virtuális magok (logikai CPU-k) számát. Bár a DTU-modell nem kínálja ezeket a lehetőségeket, a hardver típusa és az összes adatbázishoz és rugalmas készlethez használt logikai PROCESSZORok száma dinamikus felügyeleti nézeteken keresztül érhető el. Ez lehetővé teszi a megfelelő virtuális mag szolgáltatás célkitűzésének pontosabb meghatározását.

Az alábbi megközelítés ezen információk alapján határoz meg egy olyan virtuális magszolgáltatás-célkitűzést, amely hasonló erőforrás-kiosztással rendelkezik, hogy a virtuális mag modellbe való migrálás után hasonló teljesítményszintet érjen el.

DTU és virtuális mag közötti leképezés

Az alábbi Transact-SQL lekérdezés, amikor egy migrálni kívánt DTU-adatbázis kontextusában hajtják végre, a virtuális magmodell minden hardverkonfigurációjában egyező (esetleg tört) számú virtuális magot ad vissza. Ezt a számot a legközelebbi virtuális magszámra kerekítheti adatbázisokhoz és rugalmas készletekhez, a virtuális magmodell minden hardverkonfigurációjában, az ügyfelek kiválaszthatják a DTU-adatbázishoz vagy rugalmas készlethez legközelebbi virtuális magszolgáltatás-célkitűzést.

Az ezzel a módszerrel végzett migrálási példákat a Példák szakaszban találja.

Hajtsa végre ezt a lekérdezést a migrálni kívánt adatbázis kontextusában, nem pedig a master adatbázisban. Rugalmas készlet migrálásakor hajtsa végre a lekérdezést a készlet bármely adatbázisának kontextusában.

;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' --Gen4 is retired.
            WHEN slo.slo_name LIKE '%SQLGZ%' THEN 'Gen4' --Gen4 is retired.
            WHEN slo.slo_name LIKE '%SQLG5%' THEN 'standard_series'
            WHEN slo.slo_name LIKE '%SQLG6%' THEN 'standard_series'
            WHEN slo.slo_name LIKE '%SQLG7%' THEN 'standard_series'
            WHEN slo.slo_name LIKE '%GPGEN8%' THEN 'standard_series'
            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_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 * 1.7
        WHEN dtu_hardware_gen = 'standard_series' THEN dtu_logical_cpus
        END AS standard_series_vcores,
    5.05 AS standard_series_memory_per_core_gb,
    CASE 
        WHEN dtu_hardware_gen = 'Gen4' THEN dtu_logical_cpus
        WHEN dtu_hardware_gen = 'standard_series' THEN dtu_logical_cpus * 0.8
        END AS Fsv2_vcores,
    1.89 AS Fsv2_memory_per_core_gb,
    CASE 
        WHEN dtu_hardware_gen = 'Gen4' THEN dtu_logical_cpus * 1.4
        WHEN dtu_hardware_gen = 'standard_series' THEN dtu_logical_cpus * 0.9
        END AS M_vcores,
    29.4 AS M_memory_per_core_gb
FROM dtu_vcore_map;

További tényezők

A virtuális magok (logikai CPU-k) száma és a hardver típusa mellett számos más tényező is befolyásolhatja a virtuális magok szolgáltatáscéljának kiválasztását:

• A leképezési Transact-SQL lekérdezés megfelel a DTU és a virtuális mag szolgáltatás célkitűzéseinek a processzorkapacitás tekintetében, ezért az eredmények pontosabbak a processzorhoz kötött számítási feladatok esetében.

• Ugyanahhoz a hardvertípushoz és ugyanannyi virtuális maghoz az IOPS és a tranzakciónapló átviteli sebességének erőforráskorlátai gyakran magasabbak, mint a DTU-adatbázisok esetében. Az IO-hoz kötött számítási feladatok esetében lehetséges lehet csökkenteni a virtuális magok számát a virtuálismag-modellben, hogy azonos szintű teljesítményt érjenek el. A DTU- és virtuális mag adatbázisok tényleges erőforráskorlátjai a sys.dm_user_db_resource_governance nézetben jelennek meg. Az értékek összehasonlítása a migrálni kívánt DTU-adatbázis vagy -készlet, illetve egy körülbelül egyező szolgáltatási célkitűzéssel rendelkező virtuálismag-adatbázis vagy -készlet között segít Önnek pontosabban kiválasztani a virtuálismag szolgáltatási célkitűzését.

• A leképezési lekérdezés a migrálni kívánt DTU-adatbázis vagy rugalmas készlet magonkénti memóriáját, valamint a virtuális magmodell minden hardverkonfigurációját is visszaadja. A virtuális magra való migrálás után a hasonló vagy nagyobb teljes memória biztosítása fontos az olyan számítási feladatok esetében, amelyek nagy memóriaadat-gyorsítótárat igényelnek a megfelelő teljesítmény eléréséhez, vagy olyan számítási feladatok esetében, amelyek nagy memóriakivételt igényelnek a lekérdezésfeldolgozáshoz. Ilyen számítási feladatok esetén a tényleges teljesítménytől függően szükség lehet a virtuális magok számának növelésére a teljes memória eléréséhez.

• A virtuális mag szolgáltatás célkitűzésének kiválasztásakor figyelembe kell venni a DTU-adatbázis korábbi erőforrás-kihasználtságát. Konzisztensen alulhasznált CPU-erőforrásokkal rendelkező DTU-adatbázisok esetében kevesebb vCore-ra lehet szükség, mint amennyit a leképezési lekérdezés visszaad. Ellenben azokban a DTU-adatbázisokban, ahol tartósan magas a processzorhasználat, ami miatt nem megfelelő a munkaterhelés teljesítménye, több virtuális magra lehet szükség, mint amennyit a lekérdezés visszaad.

• Ha időszakos vagy kiszámíthatatlan használati mintákkal migrálja az adatbázisokat, fontolja meg kiszolgáló nélküli számítási szint használatát az Azure SQL Database számítási szinthez. A kiszolgáló nélküli környezetben egyidejűleg feldolgozók maximális száma 75% a kiépített számításban a konfigurált maximális virtuális magok számához. A kiszolgáló nélküli környezetben elérhető maximális memória a konfigurált virtuális magok maximális számának 3 GB-szorosa, ami kisebb, mint a kiépített számítás magonkénti memóriája. Gen5 esetén például a maximális memória 120 GB, ha 40 maximális virtuális mag van kiszolgáló nélküli állapotban konfigurálva, és 204 GB egy 40 virtuális magra kiosztott számításhoz.

• A vCore modellben a támogatott maximális adatbázisméret hardvertől függően eltérhet. Nagyméretű adatbázisok esetén ellenőrizze a vCore modell által támogatott maximális méreteket a önálló adatbázisok és elasztikus készletekesetében.

• Rugalmas készleteknél a rugalmas készletek erőforráskorlátjai a DTU vásárlási modell és a vCore modellek esetén eltérnek a készletenként támogatott adatbázisok maximális számában. Ezt akkor érdemes figyelembe venni, ha rugalmas készleteket migrál több adatbázissal.

• Előfordulhat, hogy egyes hardverkonfigurációk nem minden régióban érhetők el. Az SQL Database hardverkonfigurációja alatt ellenőrizze a rendelkezésre állást.

Az ebben a szakaszban szereplő irányelvek a DTU és a virtuális mag közötti méretezéshez segítenek a céladatbázis szolgáltatási célkitűzésének kezdeti becslésében.

A céladatbázis optimális konfigurációja számítási feladattól függ. Így a migrálás után az optimális ár/teljesítmény arány eléréséhez a virtuális mag modell rugalmasságát kell használnia a virtuális magok számának, a hardverkonfigurációnak, valamint a szolgáltatási és számítási szinteknek a módosításához. Előfordulhat, hogy módosítania kell az adatbázis konfigurációs paramétereit, például a párhuzamosság maximális fokát, és/vagy módosítania kell az adatbázis kompatibilitási szintjét az adatbázismotor legutóbbi fejlesztéseihez.

DTU–vCore áttelepítési példák

Standard S9-adatbázis migrálása

A leképezési lekérdezés a következő eredményt adja vissza (néhány oszlop nem jelenik meg a rövidség kedvéért):

Azt látjuk, hogy a standard DTU-adatbázis 24 logikai CPU-val (virtuális maggal) rendelkezik, virtuális magonként 5,4 GB memóriával. A közvetlen megfelelője egy általános célú 2 vCore-os adatbázis a standard sorozatú (Gen5) hardveren, amely a GP_Gen5_24 vCore szolgáltatási célt jelöli.

Standard S0-adatbázis migrálása

A leképezési lekérdezés a következő eredményt adja vissza (néhány oszlop nem jelenik meg a rövidség kedvéért):

Láthatjuk, hogy a DTU-adatbázis 0,25 logikai CPU-val (virtuális magokkal) rendelkezik, virtuális magonként 1,3 GB memóriával. A standard sorozatú (Gen5) hardverkonfiguráció legkisebb virtuális magszolgáltatás-célkitűzései, GP_Gen5_2több számítási erőforrást biztosítanak, mint a Standard S0-adatbázis, így közvetlen egyezés nem lehetséges. A GP_Gen5_2 lehetőség van előnyben. Továbbá, ha a számítási feladat megfelel a kiszolgáló nélküli számítási szintnek, akkor a GP_S_Gen5_1 közelebbi egyezést jelentene.

Prémium P15-adatbázis migrálása

A leképezési lekérdezés a következő eredményt adja vissza (néhány oszlop nem jelenik meg a rövidség kedvéért):

Láthatjuk, hogy a DTU-adatbázis 42 logikai CPU-val (virtuális maggal) rendelkezik, és virtuális magonként 4,86 GB memóriával rendelkezik. Bár nincs 42 magos vCore szolgáltatás, a BC_Gen5_40 szolgáltatás processzor- és memóriakapacitás szempontjából közel egyenértékű, és megfelelő választás.

Basic 200 eDTU rugalmas készlet migrálása

A leképezési lekérdezés a következő eredményt adja vissza (néhány oszlop nem jelenik meg a rövidség kedvéért):

Láthatjuk, hogy a rugalmas DTU-készlet 4 logikai CPU-val (virtuális magokkal) rendelkezik, virtuális magonként 5,4 GB memóriával. A standard sorozatú hardver 4 virtuális magot hív meg, azonban ez a szolgáltatási célkitűzés készletenként legfeljebb 200 adatbázist támogat, míg az Alapszintű 200 eDTU rugalmas készlet legfeljebb 500 adatbázist támogat. Ha a migrálni kívánt rugalmas készlet több mint 200 adatbázissal rendelkezik, a megfelelő virtuális mag szolgáltatás célkitűzésének GP_Gen5_6kell lennie, amely legfeljebb 500 adatbázist támogat.

Georeplikált adatbázisok migrálása

A DTU-alapú modellről a virtuális magalapú vásárlási modellre való migrálás hasonló a standard és a prémium szintű szolgáltatási szintek adatbázisai közötti georeplikációs kapcsolatok frissítéséhez vagy visszaminősítéséhez. A migrálás során nem kell leállítania a georeplikálást az általános célú és az üzleti szempontból kritikus szolgáltatási szinteken, de az alábbi sorrendszabályokat kell követnie:

• Frissítéskor előbb frissítenie kell a másodlagos adatbázist, majd frissítenie kell az elsődleges adatbázist.
• Visszalépéskor fordítsa meg a sorrendet: először az elsődleges adatbázist, majd a másodlagost kell visszaminősíteni.

Ha egy adatbázist rugalmas skálázási szolgáltatási szintre szeretne konvertálni, ideiglenesen el kell távolítani a georeplikációs szolgáltatásokat. További információért lásd: Az adatbázis átalakítása Hyperscale-vá.

Ha két rugalmas készlet között georeplikációs kapcsolatot használ, javasoljuk, hogy az egyik készletet elsődlegesként, a másikat pedig másodlagosként jelölje ki. Ebben az esetben a rugalmas készletek migrálása során ugyanazt a sorrendezési útmutatót kell használnia. Ha azonban olyan rugalmas készletekkel rendelkezik, amelyek elsődleges és másodlagos adatbázisokat is tartalmaznak, a készletet a magasabb kihasználtsággal kezelje elsődlegesként, és ennek megfelelően kövesse a szekvenálási szabályokat.

Az alábbi táblázat útmutatást nyújt adott migrálási forgatókönyvekhez:

Feladatátvételi csoportok migrálása

A több adatbázissal rendelkező feladatátvételi csoportok áttelepítéséhez az elsődleges és a másodlagos adatbázisok egyéni migrálása szükséges. A folyamat során ugyanazok a szempontok és a szekvenálási szabályok érvényesek. Miután az adatbázisok virtuális magalapú vásárlási modellté lettek konvertálva, a feladatátvételi csoport ugyanazokzal a házirend-beállításokkal marad érvényben.

Georeplikációs másodlagos adatbázis létrehozása

Georeplikációs másodlagos adatbázist (geo-másodlagos) csak az elsődleges adatbázishoz használt szolgáltatási szinttel hozhat létre. A magas naplógenerálási sebességgel rendelkező adatbázisok esetében javasoljuk, hogy az elsődleges számítási mérettel megegyező számítási méretben hozza létre a geo-másodlagost.

Ha az elsődleges adatbázishoz tartozó rugalmas készletben hoz létre geo-másodlagos adatbázist, győződjön meg róla, hogy a készlet maxVCore beállítása megegyezik az elsődleges adatbázis számítási méretével. Ha létrehoz egy geoszekundert egy másik rugalmas készletben lévő elsődlegeshez, javasoljuk, hogy a készletek ugyanazokat a maxVCore beállításokat használják.

Adatbázismásolat használata a DTU-ról való vCore-ra történő migráláshoz

adatbázis-másolat időpontban tranzakciósan konzisztens pillanatképet hoz létre az adatokról, miután a másolási művelet elindult. Az adott időpont után nem szinkronizálja az adatokat a forrás és a cél között.

Egy DTU-alapú számítási mérettel rendelkező adatbázist átmásolhat egy vCore-alapú számítási mérettel rendelkező adatbázisba a PowerShell, az Azure CLI vagy a Transact-SQL segítségével, korlátozás és speciális szekvenálás nélkül, amennyiben a cél számítási méret támogatja a forrásadatbázis maximális méretét. Az Azure Portal nem támogatja az adatbázis más szolgáltatási szintre való másolását.

Kapcsolódó tartalom

• virtuálismag-vásárlási modellt használó önálló adatbázisok erőforráskorlátai
• Erőforráskorlátok a rugalmas készletek esetében a vCore vásárlási modellnél