Megosztás a következőn keresztül:

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

  • Cikk

A következőre vonatkozik: Azure SQL Database

Ez a cikk azt ismerteti, hogyan migrálhatja az adatbázist az Azure SQL Database-ben a DTU-alapú vásárlási modellből a virtuális magalapú vásárlási modellbe.

Adatbázisok migrálása

Az adatbázis áttelepítése a DTU-alapú vásárlási modellről a virtuális magalapú vásárlási modellre hasonló, mint az alapszintű, standard és prémium szolgáltatási szintek szolgáltatási célkitűzései közötti skálázás, hasonló időtartammal és minimális állásidővel a migrálási folyamat végén. A virtuális magalapú vásárlási modellbe migrált adatbázisok bármikor, azonos módon migrálhatók a DTU-alapú vásárlási modellbe, a rugalmas skálázási szolgáltatási szintre migrált adatbázisok kivételével.

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 szintek adatbázisai és rugalmas készletei az Általános célú szolgáltatási szintre lesznek leképezve. A Prémium szolgáltatási szint adatbázisai és rugalmas készletei az üzletileg kritikus szolgáltatási szintre lesznek leképedve. 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ázisokhoz és a rugalmas készletekhez az összes DTU szolgáltatásszinten.

A virtuális mag 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 egyszerű, de hozzávetőleges hüvelykujjszabályt használhat: az alapszintű vagy a standard szinten minden 100 DTU-hoz legalább 1 virtuális mag szükséges, a Prémium szinten pedig minden 125 DTU legalább 1 virtuális magot igényel.

Tipp

Ez a szabály hozzávetőleges, mert nem veszi figyelembe a DTU-adatbázishoz vagy rugalmas készlethez használt hardvertípust.

A DTU-modellben a rendszer kiválaszthat bármilyen elérhető hardverkonfigurációt az adatbázishoz vagy a rugalmas készlethez. 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-ról virtuális magra való leképezés

Az alábbi T-SQL-lekérdezések, 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 az adatbázisokhoz és rugalmas készletekhez elérhető legközelebbi számú virtuális magra kerekítheti a virtuális magmodell minden hardverkonfigurációjában, az ügyfelek kiválaszthatják azt a virtuális magszolgáltatás-célkitűzést, amely a legközelebbi egyezés a DTU-adatbázishoz vagy a rugalmas készlethez.

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 az 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) és a hardver típusa mellett számos egyéb tényező is befolyásolhatja a virtuális magok szolgáltatáscéljának kiválasztását:

  • A 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 lesznek 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ális mag modellben, hogy azonos szintű teljesítményt érjenek el. A DTU- és virtuálismag-adatbázisok tényleges erőforráskorlátjai sys.dm_user_db_resource_governance nézetben jelennek meg. Ha összehasonlítja ezeket az értékeket a migrálni kívánt DTU-adatbázis vagy -készlet, valamint a virtuális mag-adatbázis vagy -készlet körülbelül egyező szolgáltatási célkitűzéssel való összehasonlításával pontosabban kiválaszthatja a virtuális mag szolgáltatás 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 előzményerőforrás-kihasználtságát . A konzisztensen nem használt CPU-erőforrásokkal rendelkező DTU-adatbázisoknak kevesebb virtuális magra lehet szükségük, mint a leképezési lekérdezés által visszaadott szám. Ezzel szemben azok a DTU-adatbázisok, amelyeknél a folyamatosan magas processzorkihasználtság nem megfelelő számítási teljesítményt okoz, 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 a kiszolgáló nélküli számítási szint használatát. Vegye figyelembe, hogy a kiszolgáló nélküli egyidejű feldolgozók maximális száma a kiosztott számításban megadott korlát 75%-a 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 virtuális mag modellben a támogatott maximális adatbázisméret hardvertől függően eltérhet. Nagyméretű adatbázisok esetén ellenőrizze, hogy a virtuális mag modellben támogatott maximális méretek egyetlen adatbázisok és rugalmas készletek-e.
  • Rugalmas készletek esetén a DTU- és a vCore-modellek különbséget tesznek a készletenként támogatott adatbázisok maximális száma között. Ezt figyelembe kell venni a rugalmas készletek több adatbázissal történő migrálásakor.
  • Előfordulhat, hogy egyes hardverkonfigurációk nem minden régióban érhetők el. Ellenőrizze a rendelkezésre állást az SQL Database hardverkonfigurációja alatt.

Fontos

A fenti DTU-ról virtuális magra vonatkozó méretezési irányelvek segítenek a céladatbázis-szolgáltatás 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 kihaszná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–virtuális mag áttelepítési példák

Megjegyzés:

Az alábbi példákban szereplő értékek csak illusztrációs célokra szolgálnak. A leírt forgatókönyvekben visszaadott tényleges értékek eltérhetnek.

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):

dtu_logical_cpus dtu_memory_per_core_gb standard_series_vcores standard_series_memory_per_core_gb
24.00 5.40 24.000 5.05

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. Ennek közvetlen egyezése egy általános célú 2 virtuális magos adatbázis standard sorozatú (Gen5) hardveren, a GP_Gen5_24 virtuális mag szolgáltatás célkitűzésén.

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):

dtu_logical_cpus dtu_memory_per_core_gb standard_series_vcores standard_series_memory_per_core_gb
0,25 1.3 0.500 5.05

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_2 tö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 jól megfelel a kiszolgáló nélküli számítási szintnek, akkor GP_S_Gen5_1 közelebbi egyezés lenne.

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):

dtu_logical_cpus dtu_memory_per_core_gb standard_series_vcores standard_series_memory_per_core_gb
42.00 4.86 42.000 5.05

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 virtuálismag-szolgáltatási célkitűzés, a BC_Gen5_40 szolgáltatás célkitűzése a processzor- és memóriakapacitás szempontjából majdnem egyenértékű, és jó egyezé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):

dtu_logical_cpus dtu_memory_per_core_gb standard_series_vcores standard_series_memory_per_core_gb
4.00 5.40 4.000 5.05

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_6 kell 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, 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 kell visszaminősítenie, majd a másodlagosra kell visszaminősítenie.

Ha két rugalmas készlet között georeplikációs szolgáltatást használ, javasoljuk, hogy az egyik készletet elsődlegesként, a másikat pedig másodlagosként jelölje ki. Ebben az esetben, amikor rugalmas készleteket migrál, ugyanazt a szekvenálá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:

Aktuális szolgáltatási szint Célszolgáltatás szintje Migrálás típusa Felhasználói műveletek
Standard Általános célú Oldalsó Bármilyen sorrendben migrálható, de biztosítania kell a virtuális magok megfelelő méretezését a fent leírtak szerint
Prémium Üzletileg kritikus Oldalsó Bármilyen sorrendben migrálható, de biztosítania kell a virtuális magok megfelelő méretezését a fent leírtak szerint
Standard Üzletileg kritikus Frissítés Először a másodlagos áttelepítést kell elvégeznie
Üzletileg kritikus Standard Alacsonyabb szintre Először az elsődleges áttelepítést kell elvégeznie
Prémium Általános célú Alacsonyabb szintre Először az elsődleges áttelepítést kell elvégeznie
Általános célú Prémium Frissítés Először a másodlagos áttelepítést kell elvégeznie
Üzletileg kritikus Általános célú Alacsonyabb szintre Először az elsődleges áttelepítést kell elvégeznie
Általános célú Üzletileg kritikus Frissítés Először a másodlagos áttelepítést kell elvégeznie

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 egy geo-másodlagost hoz létre a rugalmas készletben egyetlen elsődleges adatbázishoz, győződjön meg arról, hogy a maxVCore készlet beállítása megegyezik az elsődleges adatbázis számítási méretével. Ha egy másik rugalmas készletben lévő elsődleges számára hoz létre geoszekundert, javasoljuk, hogy a készletek ugyanazokat maxVCore a beállításokat használja.

Adatbázis-másolás használata dTU-ról virtuális magra való migráláshoz

A DTU-alapú számítási mérettel rendelkező adatbázisokat korlátozás és speciális szekvenálás nélkül átmásolhatja egy virtuális magalapú számítási mérettel rendelkező adatbázisba, feltéve, hogy a cél számítási méret támogatja a forrásadatbázis maximális adatbázisméretét. Az adatbázis másolása tranzakciósan konzisztens pillanatképet hoz létre az adatokról a másolási művelet elindítása utáni időponttól kezdve. Az adott időpont után nem szinkronizálja az adatokat a forrás és a cél között.

További lépések

  • Az önálló adatbázisokhoz elérhető konkrét számítási méretekről és tárméretekről az önálló adatbázisokra vonatkozó virtuális magalapú SQL Database-erőforráskorlátokat tekintheti meg.
  • A rugalmas készletekhez elérhető konkrét számítási méretekről és tárméretekről az SQL Database vCore-alapú erőforráskorlátai című témakörben olvashat.