Adatbázis fordított migrálása Hyperscale-ből

A következőkre vonatkozik:Azure SQL Database

Az Azure SQL Database-ben meglévő rugalmas skálázású adatbázisokat az Általános célú szolgáltatási szintre migrálhatja az Azure Portal, az Azure CLI, a PowerShell vagy a Transact-SQL használatával.

Az Általános célú szolgáltatási szintre való fordított migrálás lehetővé teszi, hogy azok az ügyfelek, akik nemrég konvertáltak egy meglévő adatbázist az Azure SQL Database-ben rugalmas skálázásra, vészhelyzet esetén visszaléphessenek, ha a rugalmas skálázás nem felel meg az igényeiknek. Bár a fordított migrálást egy szolgáltatási szint módosítása kezdeményezi, ez lényegében adatméret-váltás a különböző architektúrák között.

A fordított migrálás korlátozásai

A fordított migrálás a következő feltételek mellett érhető el:

• A fordított migrálás csak az eredeti Hyperscale-be történő migrálást követő 45 napon belül érhető el.
• Az eredetileg a rugalmas skálázási szolgáltatási szinten létrehozott adatbázisok nem jogosultak a fordított migrálásra.
• Előfordulhat, hogy csak az Általános célú szolgáltatási szintre visszamigrál. A rugalmas skálázásról általános célúra történő migrálás a kiszolgáló nélküli vagy a kiépített számítási szinteket is megcélozza. Ha az adatbázist egy másik szolgáltatási szintre szeretné migrálni, például üzletileg kritikus vagy DTU-alapú szolgáltatási szintre, először állítsa vissza a migrálást az Általános célú szolgáltatási szintre, majd módosítsa a szolgáltatási szintet.
• A fordított migrálás a kevesebb, mint 2 vCore-os adatbázisokba nem támogatott. A migrálás befejezése után az adatbázist lecsökkentheti kevesebb mint 2 vCore-ra.
• A rugalmas készletből vagy abba való közvetlen fordított migrálás nem támogatott. Csak egy rugalmas skálázású önálló adatbázist fordíthat vissza egy általános célú önálló adatbázisba.
  • Ha a Hyperscale adatbázis egy Hyperscale rugalmas készlet része, először el kell távolítania a Hyperscale rugalmas készletből a fordított migrálás előtt.
  • A fordított migrálás befejezése után szükség esetén hozzáadhatja az általános célú önálló adatbázist egy általános célú rugalmas készlethez.
• A fordított migrálásra nem jogosult adatbázisok esetében a rugalmas skálázásról nem rugalmas skálázású szolgáltatási szintre való migrálás egyetlen módja az exportálás/importálás bacpac-fájl vagy más adatátviteli technológiák (tömeges másolás, Azure Data Factory, Azure Databricks, SSIS stb.) használatával. Bacpac-exportálás/importálás az Azure Portalról, a PowerShellből New-AzSqlDatabaseExport vagy New-AzSqlDatabaseImport használatával, az Azure CLI-ből az sql db-exportálással és az sql db-importálással, valamint a REST API-ból nem támogatott. A bacpac-importálás/exportálás kisebb rugalmas skálázású adatbázisokhoz (150 GB-ig) támogatott az SSMS és az SqlPackage 18.4-es és újabb verzióival. Nagyobb adatbázisok esetén a bacpac exportálása/importálása hosszú időt vehet igénybe, és különböző okokból meghiúsulhat.

Időtartam és állásidő

A rugalmas skálázásban a normál szolgáltatási szintű objektív változási műveletektől eltérően a rugalmas skálázásra való migrálás és az általános célú visszatelepítés adatméretű műveletek.

A fordított áttelepítési művelet időtartama elsősorban az adatbázis méretétől és az áttelepítés során zajló egyidejű írási tevékenységektől függ. A cél általános célú adatbázishoz hozzárendelt virtuális magok száma a fordított migrálás időtartamára is hatással van. Javasoljuk, hogy a cél általános célú adatbázist a forrás rugalmas skálázású adatbázishoz hozzárendelt virtuális magok számánál nagyobb vagy egyenlő számú virtuális maggal építse ki a hasonló számítási feladatok fenntartása érdekében.

A fordított migrálás során a forrás rugalmas skálázású adatbázis teljesítménycsökkenést tapasztalhat, ha jelentős terhelés alatt áll. Pontosabban a tranzakciónaplók sebessége csökkenthető (szabályozva) annak érdekében, hogy a fordított migrálás haladjon előre.

Az új általános célú adatbázis végleges átállása során rövid, általában néhány perces állásidőre számíthat.

Előfeltételek

Mielőtt fordított migrálást kezdeményez a rugalmas skálázásról az általános célú szolgáltatási szintre, győződjön meg arról, hogy az adatbázis megfelel a fordított migrálásra vonatkozó korlátozásoknak , és:

• Az adatbázisban nincs engedélyezve a georeplikációs szolgáltatás.
• Az adatbázis nem rendelkezik elnevezett replikákkal.
• Az adatbázis (lefoglalt méret) elég kicsi ahhoz, hogy illeszkedjen a célszolgáltatási szintre.
• Ha a cél általános célú adatbázis maximális adatbázisméretét adja meg, győződjön meg arról, hogy az adatbázis lefoglalt mérete elég kicsi ahhoz, hogy beleférjen ebbe a maximális méretbe.

Az előfeltétel-ellenőrzések a fordított migrálási művelet megkezdése előtt történnek. Ha az előfeltételek nem teljesülnek, a fordított migrálási művelet azonnal meghiúsul.

Biztonsági mentési szabályzatok

A számlázás a konfigurált megőrzési időszakon belüli összes meglévő adatbázis biztonsági mentésének szokásos díjszabásával történik. Önt a hiperskálázási biztonsági mentési tár pillanatképeiért és az adattárolási blobok méretének megőrzéséért számlázzák, amelyek szükségesek a biztonsági mentés visszaállításához.

Az adatbázist Hyperscale-ra konvertálhatja, és többször visszamigrálhatja az általános célúra. A visszaállításhoz csak az adatbázis aktuális és korábbi rétegéből származó biztonsági másolatok érhetők el. Ha az Általános célú szolgáltatási szintről a Rugalmas skálázásra váltott, és visszaállt az Általános célú szolgáltatásra, az egyetlen elérhető biztonsági mentés az aktuális Általános célú adatbázisból és a közvetlenül korábbi rugalmas skálázású adatbázisból származik. Ezek a megtartott biztonsági másolatok számlázása az Azure SQL Database számlázása szerint lesz számlázva. A korábban kipróbált szintek nem rendelkeznek biztonsági másolatokkal, és nem lesznek számlázva.

Migrálhat például rugalmas skálázású és nem rugalmas skálázású szolgáltatási szintek között:

1. általános célú
2. Áttérés hiperskálázásra
3. Visszamigrálás általános célú típusra
4. A szolgáltatási szint üzleti szempontból kritikus szintre váltása
5. Áttérés hiperskálázásra
6. Visszamigrálás általános célú típusra

Ebben az esetben az egyetlen elérhető biztonsági mentés az ütemterv 5. és 6. lépéséből származik, ha még a konfigurált megőrzési időszakon belül vannak. Az előző lépések biztonsági másolatai nem érhetők el. Gondosan vegye figyelembe a biztonsági másolatok rendelkezésre állását, amikor ugyanazon adatbázis ismételt migrálását kísérli meg a rugalmas skálázás és az általános célú szolgáltatási szintek között. A közvetlenül az előző adatbázisnál régebbi adatbázisok biztonsági másolatai azonnal elérhetetlenné válnak a fordított migrálás indításakor, és akkor is elérhetetlenek maradnak, ha az áttelepítést megszakítják.

Hogyan lehet visszamigrálni egy Hyperscale adatbázist az Általános célú szolgáltatási szintre

Az Azure SQL Database-ben meglévő rugalmas skálázású adatbázisok általános célú szolgáltatási szintre való migrálásához először azonosítsa a célszolgáltatás-célkitűzést az Általános célú szolgáltatási szinten, és hogy a kiépített vagy kiszolgáló nélküli számítási szintekre szeretne-e migrálni. Tekintse át az önálló adatbázisok erőforráskorlátait , ha nem biztos abban, hogy melyik szolgáltatási célkitűzés megfelelő az adatbázishoz.

Ha az általános célúra való visszaváltás után további szolgáltatásiszint-módosítást szeretne végrehajtani, azonosítsa a végső célszolgáltatás-célkitűzést. Győződjön meg arról, hogy az adatbázis lefoglalt mérete elég kicsi ahhoz, hogy illeszkedjen az adott szolgáltatási célkitűzéshez.

Válassza ki a fülét annak a módszernek, amelyet az adatbázis visszamigrálásához előnyben részesít:

portál

Az Azure Portal lehetővé teszi az általános célú szolgáltatási szintre való migrálás megfordítását az adatbázis tarifacsomagjának módosításával.

1. Lépjen az adatbázisra az Azure Portalon.
2. A bal oldali navigációs sávon válassza a Compute + Storage lehetőséget.
3. A szolgáltatásszintek beállításainak kibontásához válassza ki a Szolgáltatási szint legördülő listát.
4. Válassza az Általános célú (Skálázható számítási és tárolási lehetőségek) lehetőséget a legördülő lista menüjében.
5. Tekintse át a felsorolt hardverkonfigurációt . Ha szükséges, válassza a Konfiguráció módosítása lehetőséget a számítási feladathoz megfelelő hardverkonfiguráció kiválasztásához.
6. Válassza ki a virtuális magok csúszkát , ha módosítani szeretné az adatbázishoz elérhető virtuális magok számát az Általános célú szolgáltatási szint alatt.
7. Válassza az Alkalmazás lehetőséget.
8. A konvertálás monitorozása az Azure Portalon.
   1. Lépjen az adatbázisra az Azure Portalon.
   2. A bal oldali navigációs sávon válassza Áttekintéslehetőséget.
   3. Tekintse át a jobb oldali ablaktábla alján található Értesítések szakaszt. Ha a műveletek folyamatban vannak, megjelenik egy értesítési mező.
   4. A részletek megtekintéséhez válassza az értesítési mezőt.
   5. Megnyílik a Folyamatban lévő műveletek ablaka. Tekintse át a folyamatban lévő műveletek részleteit.

Azure CLI

Ez a kódminta meghívja az sql db update-et egy meglévő Hyperscale adatbázis általános célú szolgáltatási szintre történő visszamigrálásához. Meg kell adnia a kiadási és a szolgáltatási célt is. Választhatja a(z) Provisioned vagy Serverless célszámítási modellt.

A következő kódminta futtatása előtt cserélje le resourceGroupName, serverName, databaseNameés serviceObjective a megfelelő értékre:

resourceGroupName="myResourceGroup"
serverName="server01"
databaseName="mySampleDatabase"
serviceObjective="GP_Gen5_2"
computeModel="Provisioned"

az sql db update -g $resourceGroupName -s $serverName -n $databaseName \
    --edition GeneralPurpose --service-objective $serviceObjective \
    --compute-model $computeModel

Az argumentumot opcionálisan is felveheti maxsize . Ha az maxsize érték meghaladja a célszolgáltatás-célkitűzés érvényes maximális méretét, a rendszer hibát ad vissza. Ha az maxsize argumentum nincs megadva, a művelet alapértelmezés szerint az adott szolgáltatási célkitűzéshez elérhető maximális méretre van bekapcsolva. Az alábbi példa meghatározza maxsize:

resourceGroupName="myResourceGroup"
serverName="server01"
databaseName="mySampleDatabase"
serviceObjective="GP_Gen5_2"
computeModel="Provisioned"
maxsize="200GB"

az sql db update -g $resourceGroupName -s $serverName -n $databaseName \
    --edition GeneralPurpose --service-objective $serviceObjective \
    --compute-model $computeModel --max-size $maxsize

Figyelje meg a folyamatban lévő műveleteket az sql db op listával. Adatbázis legutóbbi vagy folyamatban lévő műveleteinek visszaadása az Azure SQL Database-ben:

resourceGroupName="myResourceGroup"
serverName="server01"
databaseName="mySampleDatabase"

az sql db op list -g $resourceGroupName -s $serverName -n $databaseName

PowerShell

Ez a kódminta a Set-AzSqlDatabase parancsmaggal hajt végre fordított migrációt egy meglévő adatbázison a Hyperscale-ről az általános célú szolgáltatási rétegre. Meg kell adnia a kiadási és a szolgáltatási célt is. Választhatja a Provisioned vagy a Serverless a cél számítási szinthez.

A kódminta futtatása előtt cserélje le $resourceGroupNamea , $serverName, $databaseName, $serviceObjective, és $computeModel a megfelelő értékeket:

$resourceGroupName = "myResourceGroup"
$serverName = "server01"
$databaseName = "mySampleDatabase"
$serviceObjective = "GP_Gen5_2"
$computeModel = "Provisioned"

Set-AzSqlDatabase -ResourceGroupName $resourceGroupName -ServerName $serverName `
    -DatabaseName $databaseName -Edition "GeneralPurpose" -computemodel $computeModel `
    -RequestedServiceObjectiveName $serviceObjective

Az argumentumot opcionálisan is felveheti maxsize . Ha az maxsize érték meghaladja a célszolgáltatás-célkitűzés érvényes maximális méretét, a rendszer hibát ad vissza. Ha az maxsize argumentum nincs megadva, a művelet alapértelmezés szerint az adott szolgáltatási célkitűzéshez elérhető maximális méretre van bekapcsolva. Az alábbi példa meghatározza maxsize:

$resourceGroupName = "myResourceGroup"
$serverName = "server01"
$databaseName = "mySampleDatabase"
$serviceObjective = "GP_Gen5_2"
$computeModel = "Provisioned"
$maxSizeBytes = "268435456000"

Set-AzSqlDatabase -ResourceGroupName $resourceGroupName -ServerName $serverName `
    -DatabaseName $databaseName -Edition "GeneralPurpose" -computemodel $computeModel `
    -RequestedServiceObjectiveName $serviceObjective -MaxSizeBytes $maxSizeBytes

Figyelje a folyamatban lévő műveletet a Get-AzSqlDatabaseActivity parancsmaggal, amely az Azure SQL Database-ben lévő adatbázisok legutóbbi vagy folyamatban lévő műveleteit adja vissza. A mintakód futtatása előtt állítsa be a $resourceGroupName, $serverNameés $databaseName paramétereket az adatbázis megfelelő értékeire:

$resourceGroupName = "myResourceGroup"
$serverName = "server01"
$databaseName = "mySampleDatabase"

Get-AzSqlDatabaseActivity -ResourceGroupName $resourceGroupName `
    -ServerName $serverName `
    -DatabaseName $databaseName

Transact-SQL

Ha a Transact-SQL használatával vissza szeretné fordítani a rugalmas skálázású adatbázisok általános célú szolgáltatási rétegbe való migrálását, először csatlakozzon a master lévő adatbázishoz az SQL Server Management Studio (SSMS) használatával.

A kiadási és szolgáltatási célkitűzést is meg kell adnia az ALTER DATABASE utasításban.

Ez a példautasítás migrál egy mySampleDatabase nevű adatbázist az álalános célú szolgáltatási szintre, a GP_Gen5_4 szolgáltatási célkitűzéssel. Az utasítás végrehajtása előtt cserélje le az adatbázis nevét és szolgáltatáscélt a megfelelő értékekre.

ALTER DATABASE [mySampleDatabase]
    MODIFY (EDITION = 'GeneralPurpose', SERVICE_OBJECTIVE = 'GP_Gen5_2');
GO

Az argumentumot opcionálisan is felveheti maxsize . Ha az maxsize érték meghaladja a célszolgáltatás-célkitűzés érvényes maximális méretét, a rendszer hibát ad vissza. Ha az maxsize argumentum nincs megadva, a művelet alapértelmezés szerint az adott szolgáltatási célkitűzéshez elérhető maximális méretre van bekapcsolva. Az alábbi példa meghatározza maxsize:

ALTER DATABASE [mySampleDatabase]
    MODIFY (EDITION = 'GeneralPurpose', SERVICE_OBJECTIVE = 'GP_Gen5_2', MAXSIZE = 200 GB);
GO

A rugalmas skálázású adatbázisok műveleteinek monitorozásához csatlakozzon a master adatbázisához az SQL Server Management Studio (SSMS) használatával, a Visual Studio Code mssql-bővítményével vagy a választott ügyféllel Transact-SQL parancsok futtatásához.

A sys.dm_operation_status Dinamikus felügyeleti nézet lekérdezésével áttekintheti a logikai kiszolgálón lévő adatbázisokon végrehajtott legutóbbi műveletek adatait.

A sys.dm_operation_status dinamikus felügyeleti nézet a legutóbbiak szerint rendezett műveleteket ad vissza. A kódminta futtatása előtt cserélje le az adatbázis nevét a megfelelő értékre.

SELECT *
FROM sys.dm_operation_status
WHERE major_resource_id = 'mySampleDatabase'
ORDER BY start_time DESC;
GO

Kapcsolódó tartalom

• Rugalmas skálázású adatbázisok kezelése
• Meglévő adatbázis átalakítása Hyperscale