Virtuális mag vásárlási modell – Azure SQL Database

A következőkre vonatkozik:Azure SQL Database

• Azure SQL Database
• Azure SQL Managed Instance

Ez a cikk az Azure SQL DatabasevCore vásárlási modelljének áttekintését ismerteti.

Áttekintés

A virtuális mag (vCore) egy logikai PROCESSZORt jelöl, és lehetőséget kínál a hardver fizikai jellemzőinek (például a magok számának, a memória és a tárterület méretének) kiválasztására. A vCore-alapú vásárlási modell rugalmasságot, vezérlést, az egyes erőforrás-felhasználás átláthatóságát és a helyszíni számítási feladatok felhőbe való átalakításának egyszerű módját biztosítja. Ez a modell optimalizálja az árat, és lehetővé teszi a számítási feladatok igényeinek megfelelő számítási, memória- és tárolási erőforrások kiválasztását.

A vCore-alapú vásárlási modellben a költségek a választástól és a használattól függenek.

• Szolgáltatási szint
• Hardverkonfiguráció
• Számítási erőforrások (a virtuális magok száma és a memória mennyisége)
• Fenntartott adatbázis-tároló
• Valós mentéstároló

Fontos

A számítási erőforrások, az I/O, valamint az adatok és a naplótárolók díja adatbázisonként vagy rugalmas készletenként történik. A biztonsági mentési tárhelyet minden adatbázis után külön-külön kerül felszámításra. A díjszabás részleteiért tekintse meg az Azure SQL Database díjszabási oldalát.

vCore- és DTU-vásárlási modellek összehasonlítása

Az Azure SQL Database által használt vCore vásárlási modell számos előnnyel rendelkezik a DTU alapú vásárlási modell.

• Magasabb számítási, memória-, I/O- és tárolási korlátok.
• Hardverkonfiguráció kiválasztása a számítási feladat számítási és memóriakövetelményeinek jobb megfeleltetéséhez.
• Díjszabási kedvezmények az Azure Hybrid Benefit (AHB) használatával.
• Nagyobb átláthatóság a számítást használó hardveradatokban, ami megkönnyíti a helyszíni üzembe helyezésekből való migrálás tervezését.
• A fenntartott példányok díjszabása csak a virtuálismag-vásárlási modell esetén érhető el.
• Nagyobb skálázási részletesség több számítási mérettel.

Ha segítségre van szüksége a virtuális mag és a DTU vásárlási modellek közötti választáshoz, tekintse meg a virtuális mag és a DTU-alapú vásárlási modellek közötti különbségeket.

Számlál

A vCore-alapú vásárlási modell előre fenntartott számítási szinttel és kiszolgáló nélküli számítási szinttel rendelkezik. A kiosztott számítási szinten a számítási költség az alkalmazás számára folyamatosan kiosztott teljes számítási kapacitást tükrözi a számítási tevékenységétől függetlenül. Válassza ki az üzleti igényeinek leginkább megfelelő erőforrás-kiosztást a virtuális mag és a memória követelményeinek megfelelően, majd a számítási feladat igényeinek megfelelően skálázza fel és le az erőforrásokat. Az Azure SQL Database kiszolgáló nélküli számítási szintjén a számítási erőforrások automatikusan skálázódnak a számítási feladatok kapacitása alapján, és a felhasznált számítási mennyiségért számláznak másodpercenként.

Összegzés:

• Míg a kiépített számítási szint meghatározott mennyiségű számítási erőforrást biztosít, amelyek folyamatosan ki vannak építve a számítási tevékenység tevékenységétől függetlenül, a kiszolgáló nélküli számítási szint automatikusan skáláz a számítási erőforrásokat a számítási tevékenység alapján.
• Míg a kiosztott számítási szint a rögzített árú óránkénti számítási mennyiségért számláz, addig a szerver nélküli számítási szint a ténylegesen felhasznált számítás mértéke után másodpercenként számláz.

A számítási szinttől függetlenül a rendszer automatikusan lefoglal három további magas rendelkezésre állású másodlagos replikát az üzletileg kritikus szolgáltatási szinten, hogy nagy rugalmasságot biztosítson a hibákhoz és a gyors feladatátvételekhez. A további replikák következtében a költségek körülbelül 2,7-szer magasabbak az Általános célú szolgáltatási szinthez képest. Hasonlóképpen, az üzletileg kritikus szolgáltatási szint gb-onkénti magasabb tárolási költsége a helyi SSD-tároló magasabb I/O-korlátait és kisebb késését tükrözi.

Rugalmas skálázás esetén az ügyfelek a további magas rendelkezésre állású replikák számát 0-tól 4-ig szabályozhatják, hogy az alkalmazások által megkövetelt rugalmassági szintet érhessék el a költségek szabályozása során.

Az Azure SQL Database-beli számítással kapcsolatos további információkért lásd számítási erőforrások (CPU és memória).

Erőforráskorlátok

A virtuális magokra vonatkozó erőforráskorlátok esetében tekintse át az elérhető hardverkonfigurációkat, majd tekintse át a következő erőforráskorlátokat:

• logikai kiszolgálók
• önálló adatbázisok
• rugalmas készletekben lévő adatbázisok

Adatok és naplótárolás

Az alábbi tényezők befolyásolják az adatokhoz és naplófájlokhoz használt tárhely mennyiségét, és általános célú és üzleti szempontból kritikus szintekre vonatkoznak.

• Minden számítási méret támogatja a konfigurálható maximális adatméretet, alapértelmezett értéke 32 GB.
• A maximális adatméret konfigurálásakor a rendszer automatikusan hozzáadja a számlázható tárterület további 30 százalékát a naplófájlhoz.
• Az Általános célú szolgáltatási szinten tempdb helyi SSD-tárolót használ, és ez a tárolási költség a virtuális mag ára részét képezi.
• A Business Critical szolgáltatási szinten tempdb megosztja a helyi SSD-tárolót az adat- és naplófájlokkal, és tempdb tárolási költség benne foglaltatik a vCore árában.
• Az általános célú és üzleti szempontból kritikus szinteken az adatbázishoz vagy rugalmas készlethez konfigurált maximális tárterület-méretért kell fizetnie.
• AZ SQL Database esetében tetszőleges maximális adatméretet választhat 1 GB és a támogatott tárterület maximális mérete között, 1 GB-os növekményekben.

A Hyperscale-re a következő tárolási szempontok vonatkoznak:

• Az adattárolás maximális mérete 128 TB, és nem konfigurálható.
• Csak a lefoglalt adattárolásért kell fizetnie, a maximális adattárolásért nem.
• A naplótárolásért nem kell fizetnie.
• tempdb helyi SSD-tárolót használ, amelynek költségét a virtuális mag ára tartalmazza. Az SQL Database aktuális lefoglalt és használt adattárolási méretének monitorozásához használja a allocated_data_storage és tárterület Azure Monitor metrikáit.

Az adatbázisokban lévő egyes adatok és naplófájlok aktuális lefoglalt és használt tárterületének T-SQL használatával történő figyeléséhez használja a sys.database_files nézetet és a FILEPROPERTY(... , "SpaceUsed") függvényt.

Jótanács

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ó: Fájlterület kezelése az Azure SQL Database-ben.

Biztonsági mentési tár

Az adatbázis-biztonsági mentések tárolója az SQL Database időponthoz kötött visszaállítási (PITR) és hosszú távú megőrzési (LTR) képességeinek támogatására van lefoglalva. Ez a tárterület külön van az adatoktól és a naplófájlok tárolásától, és külön számlázva van.

• PITR: Az általános célú és az üzleti szempontból kritikus szinteken a rendszer automatikusan átmásolja az egyes adatbázis-biztonsági másolatokat Azure Storage-. A tárterület mérete dinamikusan nő az új biztonsági másolatok létrehozásakor. A tárhelyet teljes, differenciális és tranzakciónaplós biztonsági másolatok használják. A tárterület-felhasználás az adatbázis változási sebességétől és a biztonsági mentésekhez konfigurált megőrzési időtartamtól függ. Az SQL Database-hez minden adatbázishoz 1 és 35 nap közötti megőrzési időtartamot konfigurálhat. A beállított maximális adatméretnek megfelelő biztonsági mentési tárterületet díjmentesen biztosítjuk.
• LTR: Akár 10 évig is konfigurálhatja a teljes biztonsági másolatok hosszú távú megőrzését. Ha LTR-szabályzatot állít be, ezek a biztonsági másolatok automatikusan az Azure Blob Storage-ban lesznek tárolva, de szabályozhatja a biztonsági másolatok másolásának gyakoriságát. A különböző megfelelőségi követelmények teljesítéséhez különböző megőrzési időtartamokat választhat heti, havi és/vagy éves biztonsági mentésekhez. A választott konfiguráció határozza meg, hogy mennyi tárterületet használnak az LTR-biztonsági mentésekhez. További információ: biztonsági másolatok hosszú távú megőrzése.

A Hyperscale biztonsági mentési tárhelyéről lásd: A Hyperscale adatbázisok automatikus biztonsági mentései.

Szolgáltatási szintek

A vCore vásárlási modell szolgáltatási szintjének opciói közé tartozik az Általános Célú, az Üzleti Kritikus és a Hyperscale. A szolgáltatási szint általában meghatározza a tároló típusát és teljesítményét, a magas rendelkezésre állást és a vészhelyreállítási lehetőségeket, valamint bizonyos funkciók, például az In-Memory OLTP rendelkezésre állását.

Használati eset	általános cél	üzletileg kritikus	Hiperméretű
a legjobb számára	A legtöbb üzleti munkaterhelés. Költségvetés-orientált, kiegyensúlyozott és méretezhető számítási és tárolási lehetőségeket kínál.	Számos magas rendelkezésre állású másodlagos replika használatával biztosítja az üzleti alkalmazások számára a legnagyobb rugalmasságot a hibákkal szemben, és a legmagasabb I/O-teljesítményt nyújtja.	A számítási feladatok legszélesebb választéka, beleértve azokat a számítási feladatokat is, amelyek nagy mértékben méretezhető tárolási és olvasási követelményeket támasztanak. Nagyobb rugalmasságot biztosít a hibákkal szemben, ha több magas rendelkezésre állású másodlagos replika konfigurálását teszi lehetővé.
Számítási méret	2–128 vCores	2–128 vCores	2–128 vCores
Tárolási típus	Prémium szintű távoli tárolás (példányonként)	Szupergyors helyi SSD-tároló (példányonként)	Leválasztott tárolás helyi SSD-gyorsítótárral (minden számítási replikához)
Tárterület mérete	1 GB – 4 TB	1 GB – 4 TB	10 GB – 128 TB
IOPS	320 IOPS vCore-onként 16 000 maximális IOPS-szal	4 000 IOPS vCore-onként, 327 680 maximális IOPS-mal	327 680 IOPS maximális helyi SSD-vel A "Hyperscale" egy többrétegű architektúra, amely több szinten végez gyorsítótárazást. A hatékony IOPS a számítási feladattól függ.
Memória/vCore	5,1 GB	5,1 GB	5,1 GB vagy 10,2 GB
biztonsági másolatok	Választható georedundáns, zónaredundáns vagy helyileg redundáns biztonsági mentési tároló, 1–35 napos megőrzés (alapértelmezett 7 nap) Akár 10 évig tartó hosszú távú megőrzés	Választható georedundáns, zónaredundáns vagy helyileg redundáns biztonsági mentési tároló, 1–35 napos megőrzés (alapértelmezett 7 nap) Akár 10 évig tartó hosszú távú megőrzés	Helyileg redundáns (LRS), zónaredundáns (ZRS) vagy georedundáns (GRS) tároló kiválasztása 1-35 nap (alapértelmezés szerint 7 nap) megőrzés, legfeljebb 10 év hosszú távú megőrzési idő áll rendelkezésre
rendelkezésre állás	Egy replika, nincs olvasási skálázást végző replikák, zóna-redundáns nagy rendelkezésre állás (HA)	Három replika, egy olvasási skálázású replika, zóna-redundáns nagy rendelkezésre állás (HA)	zóna-redundáns nagy rendelkezésre állás (HA)
Díjszabás/Számlázás	vCore, fenntartott tárhely és biztonsági mentési tárhely díjat számolunk fel. Az IOPS-ok nincsenek terhelve.	vCore, fenntartott tárhely és biztonsági mentési tárhely díjat számolunk fel. Az IOPS-ok nincsenek terhelve.	vCore minden replikához és a használt tárolás költséget számolnak fel. Az IOPS-ok nincsenek terhelve.
kedvezménymodellek	Azure Reservations Azure Hybrid Benefit (fejlesztői/tesztelési előfizetésekben nem érhető el) Nagyvállalati és Fizess, amennyit használodYou-Go fejlesztés/tesztelés ajánlat előfizetések	Azure Reservations Azure Hybrid Benefit (fejlesztői/tesztelési előfizetésekben nem érhető el) Nagyvállalati és Fizess, amennyit használodYou-Go fejlesztés/tesztelés ajánlat előfizetések	Azure Hybrid Benefit (fejlesztői/tesztelési előfizetéseken nem érhető el) 1 Nagyvállalati és Fizess, amennyit használodYou-Go fejlesztés/tesztelés ajánlat előfizetések
memóriabeli OLTP-táblák	Nem	Igen	Nincs

¹ hamarosan megjelenik az SQL Database rugalmas skálázásának egyszerűsített díjszabása. A részletekért tekintse át a Hyperscale árképzés blogját.

További részletekért tekintse át logikai kiszolgáló, önálló adatbázisokés készletezett adatbázisokerőforráskorlátjait.

Megjegyzés:

A szolgáltatásiszint-szerződéssel (SLA) kapcsolatos további információkért lásd Azure SQL Database-hez készült SLA-t

Általános cél

Az általános célú szolgáltatási szint architektúramodellje a számítás és a tárolás elkülönítésén alapul. Ez az architektúramodell az Azure Blob Storage magas rendelkezésre állására és megbízhatóságára támaszkodik, amely transzparens módon replikálja az adatbázisfájlokat, és nem garantál adatvesztést, ha az alapul szolgáló infrastruktúra meghibásodása történik.

Az alábbi ábra négy csomópontot mutat be a standard architekturális modellben a különálló számítási és tárolási rétegekkel.

Az Általános célú szolgáltatási szint architektúramodelljében két réteg van:

• Egy állapot nélküli számítási réteg, amely a sqlservr.exe folyamatot futtatja, és csak átmeneti és gyorsítótárazott adatokat tartalmaz (például terv gyorsítótárat, pufferkészletet, oszlopos adattárat). Ezt az állapot nélküli csomópontot az Azure Service Fabric üzemelteti, amely inicializálja a folyamatot, szabályozza a csomópont állapotát, és szükség esetén feladatátvételt végez egy másik helyre.
• Állapotalapú adatréteg az Azure Blob Storage-ban tárolt adatbázisfájlokkal (.mdf/.ldf). Az Azure Blob Storage garantálja, hogy egyetlen adatbázisfájlban sem történik adatvesztés. Az Azure Storage beépített adat rendelkezésre állással/redundanciával rendelkezik, amely biztosítja, hogy a naplófájlban vagy az adatfájlban lévő lap összes rekordja megmaradjon akkor is, ha a folyamat összeomlik.

Amikor az adatbázismotort vagy az operációs rendszert frissítik, a mögöttes infrastruktúra egy része meghibásodik, vagy ha a sqlservr.exe folyamat kritikus problémát észlel, az Azure Service Fabric áthelyezi az állapot nélküli folyamatot egy másik állapot nélküli számítási csomópontra. Vannak olyan tartalék csomópontok, amelyek új számítási szolgáltatás futtatására várnak, ha az elsődleges csomópont feladatátvétele történik a feladatátvételi idő minimalizálása érdekében. Az Azure Storage-réteg adataira nincs hatással, és az adatok/naplófájlok az újonnan inicializált folyamathoz vannak csatolva. Ez a folyamat alapértelmezés szerint 99,99% rendelkezésre állást és 99,995% rendelkezésre állást garantál, ha zónaredundancia engedélyezve van. Az áttűnési idő és az új csomópont hideg gyorsítótárral való indítása miatt előfordulhat, hogy a nagy munkaterhelések teljesítménybeli hatással vannak a repülés közben.

Mikor válassza ki az általános célú szolgáltatási szintet?

Az Általános célú szolgáltatási szint az Azure SQL Database alapértelmezett szolgáltatási szintje, amelyet a legtöbb általános számítási feladathoz terveztek. Ha olyan teljes körűen felügyelt adatbázismotorra van szüksége, amely alapértelmezett SLA-val rendelkezik, és a tárolási késés 5 ms és 10 ms között van, az Általános célú szint az Ön számára.

Üzleti szempontból kritikus

Az üzletileg kritikus szolgáltatási szint modellje egy adatbázis-motorfolyamatok által alkotott fürtön alapul. Ez az architekturális modell az adatbázismotor-csomópontok kvórumára támaszkodik, hogy minimalizálja a számítási feladat teljesítményre gyakorolt hatását még a karbantartási tevékenységek során is. Az alapul szolgáló operációs rendszer, illesztőprogramok és adatbázismotor frissítései és javításai transzparens módon, a végfelhasználók számára minimális állásidővel történnek.

Az üzleti szempontból kritikus modellben a számítás és a tárolás minden csomóponton integrálva van. Egy négycsomópontos fürt minden csomópontján az adatbázismotor-folyamatok közötti adatreplikálás magas rendelkezésre állást biztosít, és minden csomópont helyileg csatlakoztatott SSD-t használ adattárként. Az alábbi ábra bemutatja, hogyan rendszerezi az üzletileg kritikus szolgáltatási szint az adatbázismotor-csomópontok fürtöit a rendelkezésre állási csoport replikáiban.

Az adatbázismotor folyamata és a mögöttes .mdf/.ldf fájlok ugyanazon a csomóponton vannak elhelyezve helyileg csatlakoztatott SSD-tárhellyel, így alacsony késést biztosítva a számítási feladatnak. A magas rendelkezésre állást olyan technológiával valósítják meg, amely hasonló az SQL Server Always On rendelkezésre állási csoportok technológiájához. Minden adatbázis egy adatbáziscsomópont-fürt, amely egy elsődleges replikával rendelkezik, amely elérhető az ügyfél számítási feladataihoz, és három másodlagos replika, amelyek adatmásolatokat tartalmaznak. Az elsődleges replika folyamatosan leküldi a módosításokat a másodlagos replikákra, hogy az adatok elérhetők legyenek a másodlagos replikákon, ha az elsődleges feladat valamilyen okból meghiúsul. A feladatátvételt a Service Fabric és az adatbázismotor kezeli – egy másodlagos replika lesz az elsődleges, és létrejön egy új másodlagos replika, amely biztosítja, hogy elegendő csomópont legyen a fürtben. A rendszer automatikusan átirányítja a számítási feladatot az új elsődleges replikára.

Emellett az üzletileg kritikus fürt beépített olvasási felskálázási képességgel rendelkezik, amely ingyenes csak olvasható replikát biztosít a csak olvasható lekérdezések futtatására, mint például jelentések, amelyek nem befolyásolják az elsődleges replika számítási feladatainak teljesítményét.

Mikor válassza ki az üzletileg kritikus szolgáltatási szintet?

Az üzletileg kritikus szolgáltatási szint olyan alkalmazásokhoz készült, amelyek alacsony késésű válaszokat igényelnek a mögöttes SSD-tárolóból (átlagosan 1–2 ms), gyorsabb helyreállítást, ha az alapul szolgáló infrastruktúra meghibásodik, vagy le kell tölteni a jelentéseket, elemzéseket és írásvédett lekérdezéseket az elsődleges adatbázis ingyenesen olvasható másodlagos replikájára.

Az alábbiak a legfőbb okok, amiért az üzletileg kritikus szolgáltatási szintet érdemes választania az általános célú szint helyett:

• alacsony I/O-késési követelmények – azokat a számítási feladatokat, amelyek a tárolási rétegtől folyamatosan gyors választ igényelnek (átlagosan 1–2 ezredmásodperc) üzletileg kritikus szintet kell használniuk.
• jelentéskészítési és elemzési lekérdezéseket tartalmazó számítási feladatok, ahol elegendő egyetlen ingyenes másodlagos írásvédett replika.
• Nagyobb rugalmasság és gyorsabb helyreállítás a hibákból. Rendszerhiba esetén az elsődleges példány adatbázisa le van tiltva, és az egyik másodlagos replika azonnal az új írásvédett elsődleges adatbázissá válik, amely készen áll a lekérdezések feldolgozására.
• Speciális adatsérülés elleni védelem. Mivel az üzletileg kritikus szint a háttérben adatbázis-replikákat használ, a szolgáltatás automatikus oldaljavítást alkalmaz a tükrözési és rendelkezésre állási csoportokkal az adatsérülések enyhítésére. Ha egy replika adatintegritási probléma miatt nem tud beolvasni egy lapot, a rendszer egy másik replikából kéri le a lap friss másolatát, amely adatvesztés vagy ügyfél-állásidő nélkül lecseréli az olvashatatlan lapot. Ez a funkció az Általános célú szinten érhető el, ha az adatbázis geo-másodlagos replikával rendelkezik.
• Magasabb rendelkezésre állási – A több rendelkezésre állási zóna konfigurációjának üzletileg kritikus szintje rugalmasságot biztosít a zónahibákkal szemben, és magasabb rendelkezésre állási SLA-t biztosít.
• gyors georecovery – Ha aktív georeplikáció van konfigurálva, az Üzletileg Kritikus szint garantált helyreállítási pont célkitűzése (RPO) 5 másodperc, a helyreállítási idő célkitűzése (RTO) pedig 30 másodperc, 100% üzembe helyezett óra esetén.

Nagymértékű skálázás

A rugalmas skálázású szolgáltatási szint minden számítási feladattípushoz megfelelő. Natív felhőarchitektúrája egymástól függetlenül méretezhető számítási és tárolási lehetőségeket biztosít a hagyományos és modern alkalmazások legszélesebb választékának támogatásához. A rugalmas skálázású számítási és tárolási erőforrások jelentősen meghaladják az általános célú és üzleti szempontból kritikus szinteken elérhető erőforrásokat.

További információért tekintse meg az Azure SQL DatabaseHyperscale szolgáltatási szintet .

Mikor válassza ki a rugalmas skálázású szolgáltatási szintet?

A rugalmas skálázási szolgáltatási szint eltávolítja a felhőadatbázisokban hagyományosan látható gyakorlati korlátokat. Ha a legtöbb más adatbázist egyetlen csomóponton elérhető erőforrások korlátozzák, a rugalmas skálázási szolgáltatási szinten lévő adatbázisoknak nincsenek ilyen korlátai. Rugalmas tárolási architektúrájával a rugalmas skálázású adatbázisok igény szerint növekednek , és csak a használt tárkapacitásért kell fizetnie.

A speciális skálázási képességei mellett a Hyperscale nagyszerű választás bármilyen munkaterheléshez, nem csak nagy adatbázisokhoz. Rugalmas skálázással a következőt teheti:

• A magas rendelkezésre állású replikák számának 0 és 4 közötti kiválasztásával magas rugalmasságot és gyors meghibásodási helyreállítást a költségek szabályozása mellett.
• Javítsa a magas rendelkezésre állást a zónaredundancia engedélyezésével a számításhoz és a tároláshoz.
• Alacsony I/O-késés (átlagosan 1–2 ezredmásodperc) elérése az adatbázis gyakran használt részén. Kisebb adatbázisok esetén ez a teljes adatbázisra vonatkozhat.
• Számos olvasási felskálázási forgatókönyvet valósít meg, nevesített replikákkal.
• Használja ki gyorsskálázást, anélkül, hogy várnia kellene az adatok átmásolására a helyi tárolóba az új csomópontokhoz.
• Élvezze a nulla hatással járó folyamatos adatbázis-biztonsági mentést és a gyors visszaállítást.
• A feladatátvételi csoportok és a georeplikáció használatával támogassa a üzletmenet-folytonossági követelményeket.

Hardverkonfiguráció

A virtuálismag-modell gyakori hardverkonfigurációi közé tartozik a standard sorozat (Gen5), a prémium sorozat, a memória optimalizált prémium sorozat és a DC-sorozat. A rugalmas skálázás prémium sorozatú és prémium sorozatú memóriaoptimalizált hardverekhez is kínál lehetőséget. A hardverkonfiguráció számítási és memóriakorlátokat, valamint a számítási feladatok teljesítményét befolyásoló egyéb jellemzőket határoz meg.

Bizonyos hardverkonfigurációk, például a standard sorozat (Gen5), többféle processzort (CPU) is használhatnak, amint azt a számítási erőforrások (processzor és memória) részbenleírták. Bár egy adott adatbázis vagy rugalmas készlet általában hosszú ideig (általában több hónapig) ugyanazzal a processzortípussal marad a hardveren, bizonyos események miatt az adatbázis vagy készlet más processzortípust használó hardverre helyezhető át.

Az adatbázist vagy készletet számos különböző forgatókönyv esetében lehet áthelyezni, beleértve, de nem kizárólagosan az alábbi esetekben:

• A szolgáltatás célkitűzése módosult
• Az adatközpont jelenlegi infrastruktúrája megközelíti a kapacitáskorlátokat
• A jelenleg használt hardvert az élettartam vége miatt szerelik le
• A zónaredundáns konfiguráció engedélyezve van, és a rendelkezésre álló kapacitásnak köszönhetően másik hardverre vált.

Egyes számítási feladatok esetében egy másik CPU-típusra való áttérés megváltoztathatja a teljesítményt. Az SQL Database úgy konfigurálja a hardvert, hogy kiszámítható számítási feladatteljesítményt biztosítson akkor is, ha a processzortípus megváltozik, és a teljesítményváltozásokat szűk sávon belül tartja. Az SQL Database ügyfél-számítási feladatainak széles skáláján, és az új processzortípusok elérhetővé válásával azonban időnként észrevehetőbb teljesítménybeli változások is megjelennek, ha egy adatbázis vagy készlet másik CPU-típusra vált.

A processzortípustól függetlenül az adatbázis vagy a rugalmas készlet erőforráskorlátjai (például a magok száma, a memória, a maximális adat-IOPS, a maximális naplózási sebesség és az egyidejű feldolgozók maximális száma) ugyanazok maradnak, amíg az adatbázis ugyanazon a szolgáltatási célkitűzésen marad.

Számítási erőforrások (CPU és memória)

Az alábbi táblázat a különböző hardverkonfigurációkban és számítási szinteken lévő számítási erőforrásokat hasonlítja össze:

Hardverkonfiguráció	Központi Feldolgozóegység (CPU)	Emlékezet
Standard sorozat (5. generáció)	Előre kiosztott számítási erőforrások - Intel® E5-2673 v4 (Broadwell) 2,3 GHz, Intel® SP-8160 (Skylake)*, Intel® 8272CL (Cascade Lake) 2,5 GHz*, Intel® Xeon® Platinum 8370C (Ice Lake)*, AMD EPYC 7763v (Milan) processzorok - Legfeljebb 128 hyper-szálas virtuális mag kiépítése kiszolgáló nélküli feldolgozás - Intel® E5-2673 v4 (Broadwell) 2,3 GHz, Intel® SP-8160 (Skylake)*, Intel® 8272CL (Cascade Lake) 2,5 GHz*, Intel® Xeon® Platinum 8370C (Ice Lake)*, AMD EPYC 7763v (Milan) processzorok - Automatikus skálázás akár 80 vCore-ig (hyper-threaded) – A memória és a virtuális mag közötti arány dinamikusan alkalmazkodik a memória- és processzorhasználathoz a számítási feladatok igényei alapján, és virtuális magonként akár 24 GB is lehet. Előfordulhat például, hogy egy adott időpontban egy számítási feladat 240 GB memóriát és csak 10 virtuális magot használ és számláz.	Előre kiosztott számítási erőforrások - 5,1 GB/vCore – Akár 625 GB-os kiépítés kiszolgáló nélküli feldolgozás – Automatikus skálázás virtuális magonként akár 24 GB-ig – Automatikus skálázás legfeljebb 240 GB-ig
Fsv2 sorozat**	- Intel® 8168 (Skylake) processzorok - 3,4 GHz-es tartós összes magos turbó órajellel és 3,7 GHz-es maximális egymagos turbó órajellel. – Legfeljebb 72 virtuális mag kiépítése (hiperszálas)	- 1,9 GB/vCore – Akár 136 GB kapacitás
DC-sorozat	- Intel® Xeon® E-2288G processzorok - Intel Software Guard-bővítmény (Intel SGX) – Legfeljebb 8 virtuális CPU-mag kiépítése (fizikai)	4,5 GB/vCore

* A sys.dm_user_db_resource_governance dinamikus felügyeleti nézetben az Intel® SP-8160 (Skylake) processzorokat használó adatbázisok hardvergenerációja Gen6, az Intel® 8272CL -t (Cascade Lake) használó adatbázisok hardvergenerációja Gen7, az Intel® Xeon® Platinum 8370C (Ice Lake) vagy az AMD® EPYC® 7763v (Milan) processzort használó adatbázisok hardvergenerációja gen8-ként jelenik meg. Egy adott számítási mérethez és hardverkonfigurációhoz az erőforráskorlátok a processzortípustól függetlenül azonosak (Intel Broadwell, Skylake, Ice Lake, Cascade Lake vagy AMD Milan).

** Az Fsv2 sorozatú hardverek 2026. október 1-jei kivonásra kerülnek.

További információért lásd a önálló adatbázisok és a rugalmas készletekkorlátait.

A rugalmas skálázású adatbázis számítási erőforrásairól és specifikációiról lásd rugalmas skálázású számítási erőforrásokat.

Standard sorozat (5. generáció)

A standard sorozatú (Gen5) hardver kiegyensúlyozott számítási és memória-erőforrásokat biztosít, és a legtöbb adatbázis-számítási feladathoz alkalmas.

A standard sorozatú (Gen5) hardver világszerte minden nyilvános régióban elérhető.

Rugalmas skálázású prémium sorozat

A prémium sorozatú hardverbeállítások az Intel és az AMD legújabb processzor- és memóriatechnológiáját használják. A prémium sorozat a standard sorozatú hardverhez képest növeli a számítási teljesítményt.

• A Prémium sorozat lehetőség gyorsabb processzorteljesítményt kínál a Standard sorozathoz képest, és nagyobb számú maximális virtuális magot kínál.
• A Prémium sorozatú memóriaoptimalizált beállítás a Standard sorozathoz képest megduplázza a memória mennyiségét.

Standard sorozatú, prémium sorozatú és prémium sorozatú, memóriaoptimalizált verzió érhető el a(z) rugalmas készletekhez.

További információkért lásd a Hyperscale prémium sorozat blogbejegyzését.

Az elérhető régiókról a Hyperscale prémium sorozatok rendelkezésre állásicímű témakörben olvashat.

DC-sorozat

• A DC-sorozat hardverei Intel processzorokat használnak a Software Guard Extensions (Intel SGX) technológiával.
• DC-sorozat szükséges a Always Encrypted biztonságos enklávékkal számítási feladatokhoz, amelyek erősebb biztonsági védelmet igényelnek a hardveres enklávék számára, szemben a virtualizációalapú biztonsági (VBS) enklávékkal.
• A DC-sorozat olyan számítási feladatokhoz készült, amelyek bizalmas adatokat dolgoznak fel, és bizalmas lekérdezésfeldolgozási képességeket igényelnek, amelyeket az Always Encrypted biztosít biztonságos enklávékkal.
• A DC-sorozatú hardverek kiegyensúlyozott számítási és memória-erőforrásokat biztosítanak.

A DC-sorozat csak a kiépített számítás esetében támogatott (a kiszolgáló nélküli nem támogatott), és nem támogatja a zónaredundanciát. A DC-sorozat elérhetőségét azokban a régiókban, ahol elérhető, tekintse meg itt: DC-sorozat elérhetősége.

A DC-sorozat által támogatott Azure-ajánlattípusok

Ha DC-sorozatú hardveren szeretne adatbázisokat vagy elasztikus készleteket létrehozni, az előfizetésnek olyan fizetős ajánlattípusúnak kell lennie, mint például a Használatarányos fizetés (Pay-As-You-Go)You-Go vagy Nagyvállalati Szerződés (EA). A DC-sorozat által támogatott Azure-ajánlattípusok teljes listájáért tekintse meg az költségkeret nélküli aktuális ajánlatokat.

Hardverkonfiguráció kiválasztása

Az SQL Database-ben a létrehozáskor kiválaszthatja egy adatbázis vagy rugalmas készlet hardverkonfigurációját. Egy meglévő adatbázis vagy rugalmas készlet hardverkonfigurációját is módosíthatja.

Hardverkonfiguráció kiválasztása SQL Database vagy -készlet létrehozásakor

További információ: SQL Database-létrehozása.

Az Alapszintű lapon válassza az Adatbázis konfigurálása hivatkozást a Compute + Storage szakaszban, majd válassza a Konfiguráció módosítása hivatkozást:

Válassza ki a kívánt hardverkonfigurációt:

Meglévő SQL Database vagy -készlet hardverkonfigurációjának módosítása

Adatbázis esetén az Áttekintés lapon válassza a Tarifacsomag hivatkozást:

Medence esetén az Áttekintés lapon válassza a Konfigurálás lehetőséget.

A konfiguráció módosításához kövesse a lépéseket, és válassza ki a hardverkonfigurációt az előző lépésekben leírtak szerint.

Hardver rendelkezésre állása

Az aktuális generációs hardverek rendelkezésre állásáról további információt az Azure SQL Database szolgáltatás rendelkezésre állása régiónként című témakörben talál.

Előző generációs hardver

Fsv2 sorozat

Az Azure SQL Database Fsv2 sorozatú hardverei 2026. október 1-jei kivonásra kerülnek. A szolgáltatáskimaradás minimalizálása és az ár-teljesítmény fenntartása érdekében váltson rugalmas skálázású prémium sorozatra vagy Standard sorozatú (Gen5) hardverre. További információ : Kivonási értesítés: Azure SQL Database FSV2 sorozatú ajánlat. A legtöbb adatbázis és számítási feladat esetében a rugalmas skálázású prémium sorozatú vagy Standard sorozatú (Gen5) hardverek az Fsv2-nél hasonló vagy jobb árteljesítményt biztosítanak. Annak érdekében, hogy biztos lehessen, ellenőrizze ezt a konkrét adatbázissal és terhelésekkel.

• Az Fsv2 kevesebb memóriát és tempdb biztosít virtuális magonként, mint a többi hardver, így az ezekre a korlátokra érzékeny számítási feladatok jobban teljesíthetnek a standard sorozatokon (Gen5).
• Az Fsv2 sorozat csak az Általános célú szinten támogatott.

Gen4

A Gen4-hardver ki lett állítva, és nem érhető el kiépítéshez, felskálázáshoz vagy leskálázáshoz. Az adatbázist egy támogatott hardvergenerációra migrálhatja a virtuális magok és a tárterület skálázhatóságának, a gyorsított hálózatkezelésnek, a legjobb IO-teljesítménynek és a minimális késésnek a biztosítása érdekében. Tekintse át a különálló adatbázisok hardverbeállításait és a rugalmas készletek hardverbeállításait. A Gen 4 hardver támogatása véget ért az Azure SQL Database-n, további információkért lásd: .

Következő lépés

rövid útmutató: Egyetlen adatbázis létrehozása – Azure SQL Database

Kapcsolódó tartalom

• Azure SQL Database Díjszabási Oldala
• vCore vásárlási modellt használó önálló adatbázisok számára megállapított erőforráskorlátok
• Rugalmas készletek erőforráskorlátai a vCore vásárlási modell használatával