Önálló adatbázis erőforrásainak skálázása az Azure SQL Database-ben

Ez a cikk azt ismerteti, hogyan méretezhetők az Azure SQL Database-hez elérhető számítási és tárolási erőforrások a kiépített számítási szinten. Másik lehetőségként a kiszolgáló nélküli számítási szint számítási automatikus skálázást és másodpercenkénti számlákat biztosít a felhasznált számításhoz.

A virtuális magok vagy DTU-k számának kezdeti kiválasztása után egyetlen adatbázist skálázhat fel vagy le dinamikusan a tényleges felhasználói élmény alapján:

• Transact-SQL
• Azure Portalra
• PowerShell
• Azure CLI
• REST API

Fontos

Bizonyos körülmények között előfordulhat, hogy egy adatbázist zsugorítania kell a fel nem használt terület visszaszerzéséhez. További információ: Fájltér kezelése az Azure SQL Database-ben.

Feljegyzés

A Microsoft Entra ID az Azure Active Directory (Azure AD) új neve. Jelenleg frissítjük a dokumentációt.

Hatás

A szolgáltatási szint vagy a számítási méret módosításához a szolgáltatás az alábbi lépéseket hajtja végre:

1. Hozzon létre egy új számítási példányt az adatbázishoz.

   A rendszer létrehoz egy új számítási példányt a kért szolgáltatási szinttel és számítási mérettel. A szolgáltatási szint és a számítási méret egyes kombinációihoz létre kell hozni az adatbázis replikáját az új számítási példányban, amely magában foglalja az adatok másolását, és jelentősen befolyásolhatja az általános késést. Ettől függetlenül az adatbázis ebben a lépésben online állapotban marad, és a kapcsolatok továbbra is az eredeti számítási példány adatbázisához lesznek irányítva.

2. A kapcsolatok útválasztásának váltása új számítási példányra.

   Az eredeti számítási példányban lévő adatbázis meglévő kapcsolatai megszakadnak. Minden új kapcsolat létrejön az adatbázissal az új számítási példányban. A szolgáltatási szint és a számítási méret bizonyos kombinációi esetén az adatbázisfájlok leválasztódnak és újra vannak kapcsolva a kapcsoló során. Ettől függetlenül a kapcsoló rövid szolgáltatáskimaradást okozhat, ha az adatbázis általában 30 másodpercnél rövidebb ideig és gyakran csak néhány másodpercig nem érhető el. Ha a kapcsolatok megszakadásakor hosszú ideig futó tranzakciók futnak, a megszakított tranzakciók helyreállítása hosszabb időt vehet igénybe. A gyorsított adatbázis-helyreállítás csökkentheti a hosszú ideig futó tranzakciók megszakításának hatását.

Fontos

A munkafolyamat egyik lépése sem veszett el adatok nélkül. Győződjön meg arról, hogy végrehajtott néhány újrapróbálkoztatási logikát az Azure SQL Database-t használó alkalmazásokban és összetevőkben a szolgáltatási szint módosítása során.

Késés

A szolgáltatásszint módosításához, egyetlen adatbázis vagy rugalmas készlet számítási méretének skálázásához, egy adatbázis rugalmas készletbe való áthelyezéséhez vagy egy adatbázis rugalmas készletek közötti áthelyezéséhez szükséges becsült késés az alábbiak szerint paraméterezhető:

Adatbázis skálázási késése	Alapszintű önálló adatbázishoz, Standard önálló adatbázishoz (S0-S1)	Standard önálló adatbázis (S2-S12), Általános célú önálló adatbázis,Alapszintű rugalmas készletezett adatbázis,Standard rugalmas készletezett adatbázis,Általános célú készletezett adatbázis	Prémium szintű önálló adatbázishoz vagy készletezett adatbázishoz, üzletileg kritikus önálló adatbázishoz vagy készletezett adatbázishoz	Rugalmas skálázású önálló adatbázis vagy készletezett adatbázis
Alapszintű önálló adatbázisból, Standard önálló adatbázisból (S0-S1)	• Állandó időkésés a felhasznált területétől függetlenül. • Általában kevesebb, mint 5 perc.	• Az adatmásolás miatt használt adatbázisterülettel arányos késés. • Általában kevesebb, mint 1 perc / GB felhasznált terület.	• Az adatmásolás miatt használt adatbázisterülettel arányos késés. • Általában kevesebb, mint 1 perc / GB felhasznált terület.	• Az adatmásolás miatt használt adatbázisterülettel arányos késés. • Általában kevesebb, mint 1 perc / GB felhasznált terület.
Alapszintű készletezett adatbázisból,Standard önálló adatbázisból (S2-S12), Standard készletezett adatbázisból,Általános célú önálló adatbázisból vagy készletezett adatbázisból	• Az adatmásolás miatt használt adatbázisterülettel arányos késés. • Általában kevesebb, mint 1 perc / GB felhasznált terület.	• Önálló adatbázisok esetén a felhasznált területétől független állandó időkésés. • Általában kevesebb, mint 5 perc egyetlen adatbázis esetén. • Rugalmas készletek esetén az adatbázisok számával arányos.	• Az adatmásolás miatt használt adatbázisterülettel arányos késés. • Általában kevesebb, mint 1 perc / GB felhasznált terület.	• Az adatmásolás miatt használt adatbázisterülettel arányos késés. • Általában kevesebb, mint 1 perc / GB felhasznált terület.
Prémium szintű önálló adatbázisból vagy készletezett adatbázisból, üzletileg kritikus önálló adatbázisból vagy készletezett adatbázisból	• Az adatmásolás miatt használt adatbázisterülettel arányos késés. • Általában kevesebb, mint 1 perc / GB felhasznált terület.	• Az adatmásolás miatt használt adatbázisterülettel arányos késés. • Általában kevesebb, mint 1 perc / GB felhasznált terület.	• Az adatmásolás miatt használt adatbázisterülettel arányos késés. • Általában kevesebb, mint 1 perc / GB felhasznált terület.	• Az adatmásolás miatt használt adatbázisterülettel arányos késés. • Általában kevesebb, mint 1 perc / GB felhasznált terület.
Rugalmas skálázású önálló adatbázisból vagy készletezett adatbázisból	n/a	A támogatott forgatókönyvekről és korlátozásokról lásd : Fordított migrálás rugalmas skálázásról .	n/a	• Állandó időkésés a felhasznált területétől függetlenül. • Általában kevesebb, mint 2 perc.

Feljegyzés

• A standard (S2-S12) és az általános célú adatbázisok esetében az adatbázisok rugalmas készletből vagy rugalmas készletek közötti áthelyezésének késése arányos az adatbázis méretével, ha az adatbázis prémium szintű fájlmegosztást (PFS) használ.
• Ha egy adatbázist rugalmas készletbe vagy onnan helyez át, csak az adatbázis által használt terület befolyásolja a késést, nem pedig a rugalmas készlet által használt területet.
• Annak megállapításához, hogy egy adatbázis PFS-tárolót használ-e, hajtsa végre az alábbi lekérdezést az adatbázis kontextusában. Ha az AccountType oszlop értéke vagy PremiumFileStorage-ZRSazPremiumFileStorage, az adatbázis PFS-tárolót használ.

SELECT s.file_id,
       s.type_desc,
       s.name,
       FILEPROPERTYEX(s.name, 'AccountType') AS AccountType
FROM sys.database_files AS s
WHERE s.type_desc IN ('ROWS', 'LOG');

Feljegyzés

• A zónaredundáns tulajdonság alapértelmezés szerint ugyanaz marad, amikor egyetlen adatbázist skáláz a üzletileg kritikus az Általános célú szintre.
• A skálázási művelet késése, ha egy általános célú önálló adatbázis zónaredundanciát módosít, az adatbázis méretével arányos.

Tipp.

A folyamatban lévő műveletek monitorozásához lásd: Műveletek kezelése az SQL REST API-val, műveletek kezelése parancssori felülettel, műveletek monitorozása T-SQL használatával és ez a két PowerShell-parancs: Get-AzSqlDatabaseActivity és Stop-AzSqlDatabaseActivity.

Skálázási módosítások figyelése vagy megszakítása

A szolgáltatási szint módosítása vagy a számítási újraskálázási művelet monitorozható és megszakítható.

Azure Portalra

Az SQL Database Áttekintés lapján keresse meg a skálázási műveletet jelző szalagcímet, és válassza a folyamatban lévő üzembe helyezés további hivatkozását.

Az eredményként kapott Folyamatban lévő műveletek lapon válassza a Művelet megszakítása lehetőséget.

PowerShell

A PowerShell-parancsok számítógépen való meghívásához az Az csomag 9.7.0-s vagy újabb verzióját kell helyileg telepíteni. Vagy érdemes lehet az Azure Cloud Shell használatával futtatni az Azure PowerShellt a shell.azure.com.

Először jelentkezzen be az Azure-ba, és állítsa be az előfizetés megfelelő környezetét:

Login-AzAccount
$SubscriptionID = "<YourSubscriptionIdHere>"
Select-AzSubscription -SubscriptionName $SubscriptionID

Az adatbázisok műveleteinek monitorozásához, beleértve a skálázási műveleteket is, használja a Get-AzSqlDatabaseActivity parancsot. Az alábbi minta egy-egy OperationId aktuálisan végrehajtott műveletet ad vissza.

Get-AzSqlDatabaseActivity -ResourceGroupName "ResourceGroup01" -ServerName "Server01" -DatabaseName "Database01"

Ha egy aszinkron műveletet, például egy adatbázis-méretezést szeretne megszakítani, azonosítsa a műveletet, majd használja a Stop-AzSqlDatabaseActivity parancsot egy adott OperationIdművelettel, az alábbi mintához hasonlóan.

Stop-AzSqlDatabaseActivity -ResourceGroupName "ResourceGroup01" -ServerName "Server01" -DatabaseName "Database01" -OperationId af97005d-9243-4f8a-844e-402d1cc855f5

Azure CLI

Egy Cloud Shell-terminálból az alábbi mintaparancs használatával azonosíthatja a jelenleg futó műveleteket. Egy Cloud Shell-terminálban állítsa be a $resourceGroupName, $serverNameés $databaseName változókat, majd futtassa a következő parancsot:

$resourceGroupName = "<resource group name>"
$serverName = "<server name>"
$databaseName = "<sql database name>"
az sql db op list --resource-group $resourceGroupName --server $serverName --database $databaseName --query "[?state=='InProgress'].name" --out tsv

Ha egy adatbázismérethez hasonló aszinkron műveletet szeretne leállítani egy Cloud Shell-terminálból, állítsa be az $resourceGroupName, $serverNameés $databaseName változókat, majd futtassa a következő parancsot:

$resourceGroupName = "<resource group name>"
$serverName = "<server name>"
$databaseName = "<sql database name>"
$operationName = (az sql db op list --resource-group $resourceGroupName --server $serverName --database $databaseName --query "[?state=='InProgress'].name" --out tsv)
if (-not [string]::IsNullOrEmpty($operationName)) {
    (az sql db op cancel --resource-group $resourceGroupName --server $serverName --database $databaseName --name $operationName)
        "Operation " + $operationName + " has been canceled"
}
else {
    "No service tier change or compute rescaling operation found"
}

Jogosultságok

Az adatbázisok Transact-SQL-en ALTER DATABASE keresztüli skálázásához használható. Az adatbázisok méretezéséhez a bejelentkezésnek a kiszolgáló rendszergazdai bejelentkezésének kell lennie (amelyet az Azure SQL Database logikai kiszolgáló kiépítésekor hoztak létre), a kiszolgáló Microsoft Entra-rendszergazdájának, a dbmanager-adatbázis szerepkör mastertagjának, az aktuális adatbázisban db_owner adatbázis-szerepkör tagjának vagy dbo az adatbázisnak. További információ: ALTER DATABA Standard kiadás.

Az adatbázisok Azure Portalon, PowerShellen, Azure CLI-en vagy REST API-on keresztüli skálázásához Azure RBAC-engedélyekre van szükség, különösen közreműködői, SQL DB-közreműködői vagy SQL Server-közreműködői Azure RBAC-szerepkörökre. További információkért látogasson el az Azure RBAC beépített szerepköreibe.

További szempontok

• Ha magasabb szolgáltatási szintre vagy számítási méretre vált, az adatbázis maximális mérete nem nő meg, hacsak kifejezetten nem ad meg nagyobb méretet (maxsize).
• Az adatbázis leminősítéséhez az adatbázis által használt területnek kisebbnek kell lennie a célszolgáltatásszint és a számítási méret maximális megengedett méreténél.
• A Prémium szintről a Standard szintre történő leminősítéskor további tárolási költség vonatkozik, ha (1) az adatbázis maximális mérete támogatott a cél számítási méretben, és (2) a maximális méret meghaladja a cél számítási méret belefoglalt tárterület-mennyiségét. Ha például egy 500 GB-os maximális méretű P1-adatbázis S3-ra van leképezve, akkor további tárolási költség vonatkozik, mivel az S3 támogatja az 1 TB-os maximális méretet, és a belefoglalt tárterület mennyisége csak 250 GB. A tárterület további mennyisége tehát 500 GB – 250 GB = 250 GB. Az extra tárterület díjszabását az Azure SQL Database díjszabásában talál. Ha a felhasznált terület tényleges mennyisége kisebb a belefoglalt tárterületnél, akkor ezt a többletköltséget elkerülheti, ha az adatbázis maximális méretét a belefoglalt mennyiségre csökkenti.
• Ha egy adatbázis georeplikációval van engedélyezve, frissítse másodlagos adatbázisait a kívánt szolgáltatási szintre és számítási méretre az elsődleges adatbázis frissítése előtt (általános útmutató a legjobb teljesítmény érdekében). Egy másik kiadásra való frissítéskor követelmény, hogy a másodlagos adatbázist frissítse először.
• Ha egy adatbázis georeplikációval engedélyezve van, az elsődleges adatbázisokat a kívánt szolgáltatási szintre és számítási méretre kell visszaminősíteni a másodlagos adatbázis leminősítése előtt (általános útmutatás a legjobb teljesítmény érdekében). Ha egy másik kiadásra vált, az elsődleges adatbázis leminősítésének követelménye.
• A visszaállítási szolgáltatásajánlatok eltérőek a különböző szolgáltatási szintek esetében. Ha az alapszintű szintre vált, alacsonyabb a biztonsági mentések megőrzési ideje. Tekintse meg az Azure SQL Database biztonsági mentéseit.
• Az adatbázis új tulajdonságai csak a módosítások befejeződéséig lesznek alkalmazva.
• Ha az adatbázis méretezéséhez adatmásolásra van szükség (lásd : Késés) a szolgáltatási szint módosításakor, a skálázási művelettel egyidejű magas erőforrás-kihasználtság hosszabb skálázási időt okozhat. A gyorsított adatbázis-helyreállítás (ADR) esetében a hosszú ideig futó tranzakciók visszaállítása nem jelent jelentős késleltetési forrást, de a magas egyidejű erőforrás-használat kevesebb számítási, tárolási és hálózati sávszélesség-erőforrást hagyhat a skálázáshoz, különösen kisebb számítási méretek esetén.

Számlázás

A rendszer minden órára kiszámláz egy adatbázist a legmagasabb szolgáltatási szint + az adott órában alkalmazott számítási méret alapján, a használattól függetlenül, vagy attól függetlenül, hogy az adatbázis egy óránál rövidebb ideig aktív volt-e. Ha például egyetlen adatbázist hoz létre, és öt perccel később törli azt, a számla egy adatbázisórára vonatkozó díjat tükröz.

Tárterület méretének módosítása

Virtuálismag-alapú vásárlási modell

• A tárterület legfeljebb az adattároló maximális méretkorlátja szerint építhető ki 1 GB-os növekményekkel. A minimálisan konfigurálható adattárolás 1 GB. Az adattárolás maximális méretkorlátjait az egyes szolgáltatási célkitűzésekben a virtuálismag-vásárlási modellt használó önálló adatbázisok erőforráskorlátainak dokumentációs oldalai, valamint a DTU-vásárlási modellt használó önálló adatbázisok erőforráskorlátainak dokumentációs oldalai ismertetik.

• Egy önálló adatbázis tárhelyének kiépítéséhez növelje vagy csökkentse annak maximális méretét az Azure Portalon, a Transact-SQL, a PowerShell, az Azure CLI vagy a REST API használatával. Ha a maximális méret értéke bájtban van megadva, csak az 1 GB (1 073 741 824 bájt) többszöröse lehet.

• Az adatbázis adatfájljaiban tárolható adatok mennyiségét a konfigurált adattárolás maximális mérete korlátozza. Ezen tároló mellett az Azure SQL Database automatikusan 30%-kal több tárterületet ad hozzá a tranzakciónaplóhoz. Egyetlen adatbázis vagy rugalmas készlet tárolási ára az adattárolás és a tranzakciónapló tárolási összegének szorzata a szolgáltatási szint tárolási egységárával megszorozva. Ha például az adattárolás 10 GB-ra van állítva, a tranzakciónapló további tárhelye 10 GB * 30% = 3 GB, a számlázható tárterület teljes mennyisége pedig 10 GB + 3 GB = 13 GB.

  Feljegyzés

  A tranzakciónapló-fájl maximális mérete automatikusan kezelhető, és bizonyos esetekben az adattárolás maximális méretének 30%-át is meghaladhatja. Ez nem növeli az adatbázis tárolási árát.

• Az Azure SQL Database automatikusan 32 GB-ot foglal le virtuális magonként az tempdb adatbázishoz. tempdb minden szolgáltatási szinten a helyi SSD-tárolóban található. A költségek tempdb egyetlen adatbázis vagy rugalmas készlet árában szerepelnek.

• A tárolási árakkal kapcsolatos részletekért tekintse meg az Azure SQL Database díjszabását.

Fontos

Bizonyos körülmények között előfordulhat, hogy egy adatbázist zsugorítania kell a fel nem használt terület visszaszerzéséhez. További információ: Fájltér kezelése az Azure SQL Database-ben.

DTU-alapú vásárlási modell

• Az egyetlen adatbázis DTU-ára tartalmaz egy bizonyos mennyiségű tárhelyet további költségek nélkül. Az árban foglalt tárhely további költségek megfizetésével egészen a maximális méretig növelhető. 1 TB-ig 250 GB-os növekményekben, az 1 TB elérése után pedig 256 GB-os növekményekben bővíthető a tárhely. A belefoglalt tárhelymennyiségekről és a maximális méretkorlátokról lásd: Önálló adatbázis: Tárolóméretek és számítási méretek.
• Egy önálló adatbázis tárhelyének növeléséhez növelje vagy csökkentse annak maximális méretét az Azure Portalon, a Transact-SQL, a PowerShell, az Azure CLI vagy a REST API használatával.
• Egyetlen adatbázis extra tárterületének ára a szolgáltatási szint extra tárolási egységárának szorzata. Az extra tárterület árával kapcsolatos részletekért tekintse meg az Azure SQL Database díjszabását.

Fontos

Bizonyos körülmények között előfordulhat, hogy egy adatbázist zsugorítania kell a fel nem használt terület visszaszerzéséhez. További információ: Fájltér kezelése az Azure SQL Database-ben.

Georeplikált adatbázis

A replikált másodlagos adatbázis méretének módosításához az elsődleges adatbázis méretét kell módosítani. A módosítás ezután replikálva lesz, és a rendszer implementálja a másodlagos adatbázisban is.

P11 és P15 korlátozások 1 TB-nál nagyobb maximális méret esetén

A Prémium szinten jelenleg több mint 1 TB tárterület érhető el, kivéve: Kelet-Kína, Észak-Kína, Közép-Németország és Északkelet-Németország. Ezekben a régiókban a prémium szinthez tartozó tárterület maximuma 1 TB. Az 1 TB-nál nagyobb maximális méretű P11- és P15-adatbázisokra az alábbi szempontok és korlátozások vonatkoznak:

• Ha egy P11- vagy P15-adatbázis maximális mérete valaha 1 TB-nál nagyobb értékre volt beállítva, akkor csak egy P11 vagy P15 adatbázisba állítható vissza vagy másolható. Ezt követően az adatbázis más számítási méretre skálázható át, feltéve, hogy az újraskálázási művelet során lefoglalt terület nem haladja meg az új számítási méret maximális méretkorlátját.
• Aktív georeplikációs forgatókönyvek esetén:
  • Georeplikációs kapcsolat beállítása: Ha az elsődleges adatbázis P11 vagy P15, a másodlagos adatbázisnak P11-nek vagy P15-nek is kell lennie. Az alacsonyabb számítási méreteket a rendszer másodsorban elutasítja, mivel nem képesek több mint 1 TB-ot támogatni.
  • Az elsődleges adatbázis frissítése georeplikációs kapcsolatban: Az elsődleges adatbázis maximális méretének 1 TB-nál nagyobbra történő módosítása ugyanazt a változást váltja ki a másodlagos adatbázisban. Mindkét frissítésnek sikeresnek kell lennie ahhoz, hogy az elsődleges módosítás érvénybe lépjen. Az 1 TB-nál több lehetőségre vonatkozó régiókorlátozások érvényesek. Ha a másodlagos egy olyan régióban van, amely nem támogatja az 1 TB-nál nagyobb értéket, az elsődleges nem frissül.
• A P11/P15-adatbázisok több mint 1 TB-os betöltéséhez nem támogatott az Import/Export szolgáltatás használata. Adatok importálása és exportálása az SqlPackage használatával.

Kapcsolódó tartalom

Az általános erőforráskorlátokért tekintse meg az Azure SQL Database virtuális magalapú erőforráskorlátait – az önálló adatbázisokat és az Azure SQL Database DTU-alapú erőforráskorlátait – egyetlen adatbázisokban.