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

A következőkre vonatkozik:Azure SQL Database

Ez a cikk bemutatja, hogyan skálázhatja az Azure SQL Database-hez elérhető számítási és tárolási erőforrásokat 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 automatikus skálázást biztosít a számítási kapacitáshoz és másodperc alapú számlázást a felhasznált számítási kapacitásért.

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 Portal
• PowerShell
• Azure CLI
• REST API

Fontos

Bizonyos körülmények között előfordulhat, hogy egy adatbázis zsugorítására van szükség a fel nem használt terület visszaszerzéséhez. További információ: Adatbázisok fájlterületének kezelése az Azure SQL Database-ben.

Jegyzet

Microsoft Entra ID korábban Azure Active Directory (Azure AD) néven ismert.

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 irányításának átállítása egy ú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. Bizonyos szolgáltatási szintek és számítási méretek kombinációinál az adatbázisfájlok leválasztásra kerülnek és újra csatolásra kerülnek az átállás 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. 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 implementált 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 közben.

Késlelteté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ázis (S0-S1)	Standard önálló adatbázisba (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 fontosságú önálló adatbázis vagy készletezett adatbázis	Hiperszkalálású önálló adatbázis vagy készletezett adatbázis
Alapvető egyszerű adatbázisból, Standard önálló adatbázis (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ázis (S2-S12), Standard készletezett adatbázis, Általános célú önálló adatbázis vagy készletezett adatbázis	– 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 fontosságú önálló adatbázis vagy készletezett adatbázis	– 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	Lásd a Hyperscale-ből való fordított migrálás pontban szereplő támogatott forgatókönyveket és korlátozásokat.	N/A	- Állandó időkésés a felhasznált területétől függetlenül. - Általában kevesebb, mint 2 perc.

Jegyzet

• A Standard (S2-S12) és az általános célú adatbázisok esetében az adatbázisok rugalmas készletbe vagy rugalmas készletek közötti áthelyezésének késése arányos lesz 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 PremiumFileStorage vagy PremiumFileStorage-ZRS, 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');

Jegyzet

• A zónaredundáns tulajdonság alapértelmezés szerint ugyanaz marad, amikor egyetlen adatbázist skáláz az Üzleti szempontból kritikus szintről 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.

Borravaló

A folyamatban lévő műveletek monitorozásához lásd: Műveletek kezelése az SQL REST APIhasználatával, Műveletek kezelése CLI-, Műveletek monitorozása T-SQL é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 Portal

Az SQL Database Áttekintés lapon keresse meg a bannert, amely jelzi, hogy skálázási művelet van folyamatban, és válassza a További részletek hivatkozást a folyamatban lévő telepítés megtekintéséhez.

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

PowerShell

A PowerShell-parancsok számítógépen való meghívásához telepítenie kell Az PowerShell 9.7.0-s modulját vagy egy újabb verziót helyileg. Vagy vegye fontolóra az Azure PowerShell futtatását az Azure Cloud Shell használatával a shell.azure.comoldalon.

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. Az alábbi minta egy OperationId ad vissza minden jelenleg futó művelethez.

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

Ha egy aszinkron műveletet, például egy adatbázisméretet szeretne megszakítani, azonosítsa a műveletet, majd használja a Stop-AzSqlDatabaseActivity egy adott OperationId, ahogyan az alábbi példában is szerepel.

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 az olyan aszinkron műveletet, mint például egy adatbázis méretének a megváltoztatását, szeretné leállítani egy Cloud shell terminálról, á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>"
$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"
}

Engedélyek

Az adatbázisok skálázásához a Transact-SQL: ALTER DATABASE 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 tagjának master, az aktuális adatbázisban a db_owner adatbázis-szerepkör tagjának vagy az adatbázis dbo. További információkért lásd: ALTER DATABASE.

Adatbázisok azure portalon, PowerShellen, Azure CLI-en vagy REST API-keresztüli skálázásához: Azure RBAC-engedélyekre van szükség, különösen a Közreműködő, az SQL DB közreműködői szerepkörére vagy az SQL Server közreműködői Azure RBAC-szerepkörére. További információ: Azure RBAC beépített szerepkörei.

További szempontok

• Ha magasabb szolgáltatási csomagra vagy számítási méretre frissít, az adatbázis maximális mérete nem nő automatikusan, csak akkor, ha explicit módon ad meg egy nagyobb méretet (maximális méret beállítása, 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.
• Az Premium-rő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 árazását lásd az Azure SQL Database díjszabási. 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ázist georeplikációs engedélyezve van, 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.
• Amikor egy adatbázisban engedélyezett georeplikációval végrehajt downgrade-et, mindig először az elsődleges adatbázisokat kell a kívánt szolgáltatási szintre és számítási méretre visszaminősíteni, majd a másodlagos adatbázist (általános útmutató a legjobb teljesítmény érdekében). Amikor egy másik kiadásra vált, muszáj, hogy először az elsődleges adatbázis leminősítésére kerüljön sor.
• A visszaállítási szolgáltatásajánlatok eltérőek a különböző szolgáltatási szintekhez. Ha a Alapszintű szintre vált, a biztonsági mentések megőrzési ideje rövidebb lesz. Lásd: Automatikus biztonsági mentések az Azure SQL Database-ben.
• 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ési) 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ásiesetén 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ális processzormag-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 egyes szolgáltatási célkitűzések adattárolásának maximális méretkorlátjait az erőforráskorlátok dokumentációs oldalain találja meg: Az önálló adatbázisok erőforráskorlátai a vCore vásárlási modellt használva, és az erőforráskorlátok a DTU vásárlási modellt használva.

• Az egyetlen adatbázishoz tartozó adattárolás az Azure Portal , Transact-SQL, PowerShell-, Azure CLIvagy REST APIhasználatával növelhető vagy csökkenthető. Ha a maximális méretérték bájtban van megadva, annak 1 GB többszörösének kell lennie (1 073 741 824 bájt).

• Az adatbázis adatfájljaiban tárolható adatok mennyiségét a konfigurált adattárolás maximális mérete korlátozza. A tároló mellett az Azure SQL Database automatikusan hozzáad 30% további tárterületet a tranzakciónaplóhoz. A egyetlen adatbázis vagy rugalmas készlet tárolási ára megegyezik az adattárolási és tranzakciónapló tárolási mennyiségek összegével, amit megszorzunk a szolgáltatási szint tárolási egységárával. Például, ha az adattárolás 10 GBvan beállítva, a további tranzakciónapló-tárterület 10 GB * 30% = 3 GBlesz, és a számlázható tárterület teljes mennyisége 10 GB + 3 GB = 13 GB.

  Jegyzet

  A tranzakciónapló-fájl maximális mérete automatikusan kezelhető, és bizonyos esetekben nagyobb lehet, mint 30% az adattárolás maximális mérete. 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 a tempdb adatbázishoz. tempdb minden szolgáltatási szinten a helyi SSD-tárolóban található. A tempdb költsége egyetlen adatbázis vagy rugalmas készlet árában szerepel.

• A tárolási árakkal kapcsolatos részletekért lásd Azure SQL Database díjszabási.

Fontos

Bizonyos körülmények között előfordulhat, hogy egy adatbázis zsugorítására van szükség a fel nem használt terület visszaszerzéséhez. További információ: Adatbázisok fájlterületének kezelése az Azure SQL Database-ben.

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

• Az egyes adatbázisok DTU ára tartalmaz egy bizonyos mennyiségű tárhelyet további költségek nélkül. A belefoglalt mennyiségen túl további tárterületet is ki lehet állítani a maximális méretkorlátig 250 GB-os, legfeljebb 1 TB-os növekményekben, majd 256 GB-os, 1 TB-nál nagyobb növekményekben. A belefoglalt tárterület-mennyiségekkel és a maximális méretkorlátokkal kapcsolatban lásd önálló adatbázis: A tárterület méretei és számítási méretei.
• Egyetlen adatbázishoz külön tárterületet lehet igénybe venni a maximális méretének növelésével az Azure portál, Transact-SQL, PowerShell, az Azure CLIvagy a REST APIhaszná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 lásd Azure SQL Database díjszabási.

Fontos

Bizonyos körülmények között előfordulhat, hogy egy adatbázis zsugorítására van szükség a fel nem használt terület visszaszerzéséhez. További információ: Adatbázisok fájlterületének kezelése az Azure SQL Database-ben.

Georeplikált adatbázis

A replikált másodlagos adatbázisok adatbázisméretének módosításához módosítsa az elsődleges adatbázis méretét. Ezt a módosítást ezután replikáljuk és implementáljuk 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 szintű tárterület maximális kapacitása 1 TB-ra korlátozódik. 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ó. Később az adatbázis más számítási méretre is átméretezhető, 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. Az SqlPackage használatával importálhat és exportálhat adatokat.

Kapcsolódó tartalom

• vCore vásárlási modellt használó egyedi adatbázisok erőforrás-korlátai
• DTU vásárlási modellt használó önálló adatbázisok erőforráskorlátai – Azure SQL Database