Rugalmas skálázású szolgáltatási szint
A következőkre vonatkozik:
Azure SQL Database
Az Azure SQL Database az SQL Server Adatbázismotor architektúráján alapul, amely a felhőkörnyezethez van igazítva, hogy magas rendelkezésre állású még infrastruktúrahibák esetén is. Az Azure SQL Database virtuális mag vásárlási modelljében három szolgáltatási szint közül választhat:
- Általános cél
- Üzleti szempontból kritikus
- Hiperlépté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őbeli architektúrája egymástól függetlenül skálázható számítást és tárolást 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.
A vCore-alapú vásárlási modell Általános célú és Üzletileg kritikus szolgáltatási szintjeiről további információt a Általános célú és a Üzletileg kritikus szolgáltatási szintek szakaszban talál. Az Azure SQL Database vCore-alapú vásárlási modelljének és a DTU-alapú vásárlási modelljének összehasonlításához lásd: Az Azure SQL Database vCore- és DTU-alapú vásárlási modelljeinek összehasonlítása.
A rugalmas skálázású szolgáltatási szint jelenleg csak az Azure SQL Database-hez érhető el, felügyelt Azure SQL-példányhoz nem.
Mik a hiperskálázható képességek?
Az Azure SQL Database rugalmas skálázási szolgáltatási szintje a következő további képességeket biztosítja:
- Gyors vertikális felskálázás – állandó időben felskálázhatja a számítási erőforrásokat, hogy szükség esetén elférjenek a nagy számítási feladatok, majd szükség esetén visszaskálázhatja a számítási erőforrásokat.
- Gyors felskálázás – üzembe helyezhet egy vagy több csak olvasható replikát az olvasási terhelés kiszervezéséhez és készenléti példányként való használatra.
- A számítás felskálázása, leskálázása és számlázása automatikusan a használat alapján, kiszolgálónélküli számítással .
- Ár/teljesítmény optimalizálása különböző erőforrásigényű hyperscale adatbázisok egy csoportjához a rugalmas készletekhasználatával.
- A tároló automatikus méretezése akár 128 TB adatbázis vagy 100 TB rugalmas készletméret támogatásával.
- Nagyobb általános teljesítmény a nagyobb tranzakciónapló-átviteli sebesség és a gyorsabb tranzakció-véglegesítési idő miatt, függetlenül az adatmennyiségtől.
- Gyors adatbázis-biztonsági mentések (fájlpillanatképek alapján) mérettől függetlenül, I/O-hatás nélkül a számítási erőforrásokra.
- Az adatbázis gyors visszaállítása vagy másolása (a fájl pillanatképei alapján) órák vagy napok helyett percek alatt történik.
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 tárolás igény szerint növekszik. A rugalmas skálázású adatbázisok valójában nem meghatározott maximális mérettel jönnek létre. A rugalmas skálázású adatbázisok igény szerint növekednek, és csak a lefoglalt tárkapacitásért kell fizetnie. Olvasásintenzív számítási feladatok esetében a Hyperscale szolgáltatási szint gyors skálázást biztosít az olvasási számítási feladatok leterheltségének csökkentéséhez szükséges további replikák kiépítésével.
Emellett az adatbázis biztonsági mentéseinek létrehozásához, illetve a vertikális fel- vagy leskálázáshoz szükséges idő már nem kapcsolódik az adatbázis adatmennyiségéhez. A rugalmas skálázású adatbázisokról gyakorlatilag azonnal biztonsági másolatot készít a rendszer. Az adatbázisokat percek alatt fel- vagy leskálázhatja a kiosztott számítási szinten, vagy kiszolgáló nélküli használatával automatikusan skálázhatja a számítást. Ez a funkció megszabadít a kezdeti konfigurációs lehetőségek által bekeretezett problémáktól.
A rugalmas skálázású szolgáltatási szint számítási méreteiről további információt Szolgáltatásszint jellemzőicímű témakörben talál.
Kinek érdemes figyelembe vennie a rugalmas skálázású szolgáltatási szintet?
A rugalmas skálázási szolgáltatási szint minden olyan ügyfélnek szól, aki nagyobb teljesítményt és rendelkezésre állást, gyors biztonsági mentést és visszaállítást, valamint/vagy gyors tárolást és számítási méretezhetőséget igényel. Ez magában foglalja azokat az ügyfeleket, akik a felhőbe költöznek, hogy modernizálják az alkalmazásaikat és azokat az ügyfeleket, akik már más szolgáltatási szinteket használnak az Azure SQL Database-ben. A rugalmas skálázású szolgáltatási szint számos adatbázis-számítási feladatot támogat, a tiszta OLTP-től a tiszta elemzésig. OLTP és hibrid tranzakciós és elemzési (HTAP) számítási feladatokhoz van optimalizálva.
Rugalmas skálázási díjszabási modell
Jegyzet
Megérkezett az Azure SQL Database Hyperscale egyszerűsített árazása! Tekintse át az Azure SQL Database Hyperscale új árképzési szintjénekbejelentését, és a díjszabásváltozás részleteiért tekintse meg a Azure SQL Database Hyperscale – alacsonyabb, egyszerűsített árazást!.
A hiperskálázású szolgáltatási szint csak a virtuálismag-modellbenérhető el. Az új architektúrához igazodva a díjszabási modell kissé eltér az általános célú vagy az üzletileg kritikus szolgáltatási szintektől:
Előre kiosztott számítási kapacitás:
A hiperskála számítási egység ára replikánként van meghatározva. A felhasználók a rendelkezésre állási és méretezhetőségi követelményektől függően 0-tól 4-ig módosíthatják a magas rendelkezésre állású másodlagos replikák teljes számát, és legfeljebb 30 elnevezett replikát hozhatnak létre a különböző olvasási horizontálisan felskálázott számítási feladatok támogatásához.
hu-HU: kiszolgáló nélküli számítás:
A kiszolgáló nélküli számítási számlázás a használaton alapul. További információ: Kiszolgáló nélküli számítási szint az Azure SQL Database.
Tároló:
Rugalmas skálázású adatbázisok konfigurálásakor nem kell megadnia a maximális adatméretet. A Hyperscale szintben az adatbázis tárhelyéért a tényleges kiosztás alapján kell fizetnie. A tárterület automatikusan 10 GB és 128 TB között van lefoglalva, és igény szerint 10 GB-os növekményben növekszik.
A Hyperscale díjszabásáról további információkat Azure SQL Database díjszabásioldalon talál.
Elosztott függvények architektúrája
A rugalmas skálázás elválasztja a lekérdezésfeldolgozó motort azoktól az összetevőktől, amelyek hosszú távú tárolást és tartósságot biztosítanak az adatok számára. Ez az architektúra lehetővé teszi a tárolási kapacitás igény szerinti zökkenőmentes skálázását (akár 128 TB-ig), valamint a számítási erőforrások gyors méretezését.
Az alábbi ábra a funkcionális rugalmas skálázási architektúrát mutatja be:
További információ a rugalmas skálázású elosztott függvények architektúrájáról.
Skálázási és teljesítménybeli előnyök
A Hyperscale architektúra lehetővé teszi, hogy gyorsan indíthatóak vagy leállíthatóak legyenek további csak-olvasási számítási csomópontok, ezáltal jelentős olvasási teljesítmény skálázási képességeket biztosítva, és felszabadítva az elsődleges számítási csomópontot több írási kérelem kiszolgálására. A számítási csomópontok a rugalmas skálázási architektúra megosztott tárolási architektúrája miatt gyorsan fel- és leskálázhatók. A Hyperscale rugalmas skálázású írásvédett számítási csomópontjai a kiszolgáló nélküli számítási szintis elérhetők, amely automatikusan skálázza a számítást a munkaterhelés igényei alapján.
Adatbázis magas szintű rendelkezésre állása a Hyperscale-ben
Az összes többi szolgáltatási szinthez hasonlóan a Hyperscale is garantálja az adatok tartósságát a véglegesített tranzakciókhoz, függetlenül a számítási replikák elérhetőségétől. Az elsődleges replika elérhetetlenné válása miatti állásidő mértéke függ a feladatátvétel típusától (tervezett és nem tervezett), , hogy a zónaredundanciavan-e konfigurálva, és hogy legalább egy magas rendelkezésre állású replika van-e. Tervezett feladatátvétel (például karbantartási esemény) esetén a rendszer vagy létrehozza az új elsődleges replikát a feladatátvétel kezdeményezése előtt, vagy egy meglévő magas rendelkezésre állású replikát használ feladatátvételi célként. A nem tervezett feladatátvétel (például az elsődleges replika hardverhibája) esetén a rendszer egy magas rendelkezésre állású replikát használ feladatátvételi célként, ha van ilyen, vagy létrehoz egy új elsődleges replikát a rendelkezésre álló számítási kapacitás készletéből. Az utóbbi esetben az állásidő hosszabb az új elsődleges másolat létrehozásához szükséges további lépések miatt.
Kiválaszthatja egy karbantartási időszakot, amely lehetővé teszi a jelentős karbantartási események kiszámíthatóvá és kevésbé zavaróvá tétele a számítási feladat számára.
A rugalmas skálázású SLA-ról az Azure SQL Database SLA-jában olvashat.
Pufferkészlet, rugalmas pufferkészlet-bővítmény és folyamatos feltöltés
Az Azure Database Hyperscale szolgáltatásban a számítás és a tárhely külön van választva. A Storage egy adatbázis összes adatbázisoldalát tartalmazza, és az adatbázis növekedésével több gépen is lefoglalható. A számítási csomópont azonban csak a közelmúltban használt adatokat gyorsítótárazza. A számítás legforróbb lapjai a memóriában maradnak egy pufferkészlet (BP) nevű struktúrában. A rendszer a helyi SSD-ben, a rugalmas pufferkészletbővítményben (RBPEX) is tárolja, így gyorsabban lekérhetők az adatok, ha a számítási folyamat újraindul.
A felhőrendszerben a számítás szükség szerint különböző gépekre válthat. A számítási réteg több replikával is rendelkezhet. Az egyik elsődleges, és minden frissítést megkap, míg a többi másodlagos replika. Elsődleges hiba esetén az egyik magas rendelkezésre állású másodlagos replika gyorsan előléptethető elsődlegesként a feladatátvétel nevű folyamat során. Előfordulhat, hogy a másodlagos replika nem rendelkezik gyorsítótárral a BP-ben és az RBPEX-ben, amely az elsődleges számítási feladathoz van optimalizálva.
A folyamatos priming egy olyan folyamat, amely információkat gyűjt arról, hogy mely lapok a legforróbbak az összes számítási replikában. Az információ összesítve van, és a magas rendelkezésre állású másodlagos replikák a tipikus ügyfélterhelésnek megfelelő legforróbb oldalak listáját használják. Így a BP és az RBPEX is folyamatosan feltölti a leggyakrabban használt lapokat, hogy lépést tartson az ügyfél számítási feladatainak változásaival.
Folyamatos előkészítés nélkül a BP és az RBPEX nem öröklődik az új magas rendelkezésre állású replikáktól, és csak a felhasználói munkaterhelés során lesz rekonstruálva. A folyamatos feltöltés időt takarít meg, és megakadályozza az inkonzisztens teljesítményt, mivel nincs várakozás, mielőtt a gyorsítótárak újra teljesen hidratálódnak. A folyamatos feltöltéssel az új magas rendelkezésre állású másodlagos replikák azonnal megkezdik a BP és az RBPEX feltöltését. Ez segít a teljesítmény konzisztensebb fenntartásában a feladatátvételek bekövetkeztekor.
A folyamatos előkészítés mindkét módon működik: a magas rendelkezésre állású másodlagos replikák gyorsítótárazzák az elsődleges replikában használt lapokat, az elsődleges pedig a másodlagos replikák számítási feladatával rendelkező lapokat gyorsítótárazza.
Jegyzet
A folyamatos előkészítés jelenleg korlátozott előzetes verzióban érhető el, és nem érhető el kiszolgáló nélküli adatbázisokhoz. További információkért és a folyamatos előtolás engedélyezéséhez lásd Blog: 2024. november Rugalmas skálázású fejlesztések.
Biztonsági mentés és visszaállítás
A rugalmas skálázású adatbázisok biztonsági mentési és visszaállítási műveletei fájl-pillanatkép-alapúak. Ez lehetővé teszi, hogy ezek a műveletek szinte azonnaliak legyenek. Mivel a rugalmas skálázású architektúra a tárolási réteget használja a biztonsági mentéshez és a visszaállításhoz, a számítási replikák feldolgozási terhe és teljesítménye csökken. További információ rugalmas skálázású biztonsági mentésekről és a tárolóredundanciákról.
Rugalmas skálázású adatbázisok vészhelyreállítása
Ha az Azure SQL Database-ben található rugalmas méretezésű adatbázist a jelenlegi régiójától eltérő régióba kell visszaállítania, például egy katasztrófa utáni helyreállítási művelet, próba, áthelyezés vagy bármely más okból, az elsődleges módszer az adatbázis geo-visszaállítása. A georedundáns visszaállítás csak akkor érhető el, ha a georedundáns tárolás (RA-GRS) lett kiválasztva a tárolóredundanciához.
Ismerje meg, hogyan lehet egy Hyperscale adatbázist másik régióbavisszaállítani.
Erőforráskorlátok összehasonlítása
A vCore-alapú szolgáltatási szintek az adatbázis rendelkezésre állása, a tárhelytípus, a teljesítmény és a tárterület maximális mérete alapján vannak megkülönböztetve. Ezeket a különbségeket a következő táblázatban ismertetjük:
| ㅤ | általános célú | üzletileg kritikus | hiperskálázás |
|---|---|---|---|
| a legjobb | Költségvetés-orientált, kiegyensúlyozott számítási és tárolási lehetőségeket kínál. | Magas tranzakciós sebességgel és alacsony I/O-késéssel rendelkező OLTP-alkalmazások. Nagy fokú rugalmasságot biztosít a hibákkal szemben és gyors hibatűrést kínál több aktív készenléti replika használatával. | A számítási feladatok legszélesebb választéka. A tárterület automatikus méretezése akár 128 TB-ig, gyors függőleges és vízszintes számítási méretezés, gyors adatbázis-visszaállítás. |
| Számítás mérete | 2–128 vCores | 2–128 virtuális processzormag | 2-tól 128-ig virtuális mag |
| Tárolás típusa | 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 virtuális magonként, 16 000 maximális IOPS mellett | 4 000 IOPS virtuális magonként 327 680 maximális IOPS mellett | 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 |
| rendelkezésre állás | Egy replika, nincs olvasási terheléselosztás, zónaredundáns magas rendelkezésre állás | Három replika, egy olvasási felskálázás, zónaredundáns HA | Több replika, legfeljebb négy olvasási felskálázás, zónaredundáns HA |
| biztonsági másolatok | Helyileg redundáns (LRS), zónaredundáns (ZRS) vagy georedundáns (GRS) tároló kiválasztása 1-35 nap (alapértelmezés szerint hét nap) megőrzés, legfeljebb 10 év hosszú távú megőrzési idő áll rendelkezésre |
Helyileg redundáns (LRS), zónaredundáns (ZRS) vagy georedundáns (GRS) tároló kiválasztása 1-35 nap (alapértelmezés szerint hét nap) megőrzés, legfeljebb 10 év hosszú távú megőrzési idő áll rendelkezésre |
Helyileg redundáns (LRS), zónaredundáns (ZRS) vagy georedundáns (GRS) tároló kiválasztása 1-35 nap (alapértelmezés szerint hét nap) megőrzés, legfeljebb 10 év hosszú távú megőrzési idő áll rendelkezésre |
| díjszabási/számlázási |
vCPU, fenntartott tárhely és biztonsági mentési tárhely díjat számítunk fel. IOPS-ért nem számítunk fel díjat. |
vCPU, fenntartott tárhely és biztonsági mentési tárhely díjat számítunk fel. IOPS-ért nem számítunk fel díjat. |
virtuális mag az egyes replikákhoz, a lefoglalt adattároláshoz és a biztonsági mentési tárhelyhez kerül felszámításra. IOPS-ért nem számítunk fel díjat. |
| Kedvezményes modellek1 |
fenntartott példányok Azure Hybrid Benefit2 Nagyvállalati és Fizess ahogy fejleszt/testelYou-Go ajánlat előfizetések |
fenntartott példányok Azure Hybrid Benefit2 Nagyvállalati és Fizess ahogy fejleszt/testelYou-Go ajánlat előfizetések |
Fenntartott példányok Azure Hybrid Benefit2 Nagyvállalati és Fizess ahogy fejleszt/testelYou-Go ajánlat előfizetések |
1 2023 decemberében megérkezett az SQL Database Hyperscale egyszerűsített díjszabása. A részletekért tekintse át a Hyperscale árképzés blogját.
2 2023. decemberétől az Azure Hybrid Benefit nem érhető el új rugalmas skálázású adatbázisokhoz vagy fejlesztői/tesztelési előfizetésekhez. A kiépített számítással rendelkező meglévő rugalmas skálázású önálló adatbázisok 2026 decemberéig továbbra is használhatják az Azure Hybrid Benefitet a számítási költségek megtakarítására. További információ: Rugalmas skálázású díjszabási blog.
Számítási erőforrások
| Hardverkonfiguráció | CPU (központi feldolgozó egység) | Emlékezet |
|---|---|---|
| Standard-sorozat (Gen5) |
kiépített számítási erőforrások - Intel® E5-2673 v4 (Broadwell) 2,3 GHz, Intel® SP-8160 (Skylake)1, Intel® 8272CL (Cascade Lake) 2,5 GHz1, Intel® Xeon® Platinum 8370C (Ice Lake)1, AMD EPYC 7763v (Milan) processzorok – Legfeljebb 80 virtuális mag kiépítése (szimultán többszálú) kiszolgáló nélküli számítás - Intel® E5-2673 v4 (Broadwell) 2,3 GHz, Intel® SP-8160 (Skylake)1, Intel® 8272CL (Cascade Lake) 2,5 GHz1, Intel® Xeon® Platinum 8370C (Ice Lake)1, AMD EPYC 7763v (Milan) processzorok - Automatikus skálázás 80 virtuális magig (hiperszálas) – 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. |
kiépített számítási erőforrások - 5,1 GB/virtuális mag – Akár 625 GB-os kiépítés kiszolgáló nélküli számítás – Automatikus skálázás virtuális magonként akár 24 GB-ig – Automatikus skálázás legfeljebb 240 GB-ig |
| Prémium sorozat | - Intel® Xeon® Platinum 8370C (Ice Lake), AMD EPYC 7763v (Milan) processzor - Legfeljebb 128 virtuális processzormag kiépítése (hyper-threaded) |
- 5,1 GB/vCore |
| Prémium sorozat, memóriaoptimalizált | - Intel® Xeon® Platinum 8370C (Ice Lake), AMD EPYC 7763v (Milan) processzor – Legfeljebb 80 virtuális mag kiépítése (szimultán többszálú) |
- 10,2 GB/vCore |
1 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 néven jelenik meg. Egy adott számítási méret és hardverkonfiguráció esetében az erőforráskorlátok a processzortípustól függetlenül azonosak. További információért lásd: önálló adatbázisok és rugalmas készletek.
A kiszolgáló nélküli rendszer csak standard sorozatú (Gen5) hardvereken támogatott.
Rugalmas skálázású adatbázisok létrehozása és kezelése
Rugalmas skálázású adatbázisokat az Azure Portal, a Transact-SQL, a PowerShell és az Azure CLI használatával hozhat létre és kezelhet. További információ: Rövid útmutató: Rugalmas skálázású adatbázis létrehozása.
| művelet | Részletek | További információ |
|---|---|---|
| Rugalmas skálázású adatbázis létrehozása | Hiperskálázható adatbázisok csak a VCore-alapú vásárlási modellhasználatával érhetők el. | Példákat talál a rugalmas skálázású adatbázisok létrehozásához rövid útmutatóban: Rugalmas skálázású adatbázis létrehozása az Azure SQL Database-ben. |
| Meglévő adatbázis frissítése hiperméretezésre | Az Azure SQL Database-ben meglévő adatbázis Hyperscale szintre való migrálása egy nagy méretű adatművelet. | Ismerje meg , hogyan migrálhat egy meglévő adatbázist a Hyperscale-be. |
| Rugalmas skálázású adatbázisok fordított migrálása az Általános célú szolgáltatási szintre | Ha korábban már telepített át egy meglévő Azure SQL Database-adatbázist rugalmas skálázásra, az adatbázist az eredeti rugalmas skálázásra való migrálást követő 45 napon belül visszatelepítheti az általános célú szolgáltatási szintre. Ha át szeretné telepíteni az adatbázist egy másik szolgáltatási szintre (például üzleti szempontból kritikus 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. |
Ismerje meg , hogyan fordíthatja vissza a migrálást a Hyperscale-ról, beleértve a korlátozásokat a fordított áttelepítéssorán. |
Korlátozások
Ezek a rugalmas skálázási szolgáltatási szint jelenlegi korlátozásai. Aktívan dolgozunk azon, hogy a lehető legtöbb korlátozást eltávolítsuk.
| Kérdés | Leírás |
|---|---|
| A zsugorítás blokkolva van, ha a TDE tiltva van. | Az adatbázis- és fájlzsugorítási műveletek jelenleg nem támogatottak, ha a transzparens adattitkosítás (TDE) le van tiltva az Azure SQL Database rugalmas skálázásában. |
| Adatbázis visszaállítása más szolgáltatási szintekről | A nem rugalmas skálázású adatbázisok nem állíthatók vissza rugalmas skálázású adatbázisként, és a rugalmas skálázású adatbázisok nem állíthatók vissza nem rugalmas skálázású adatbázisként. Más Azure SQL Database szolgáltatási szintekről a Hyperscale-be migrált adatbázisok esetében az áttelepítés előtti biztonsági másolatokat a forrásadatbázis biztonsági mentési időtartamára megőrizzük, beleértve a hosszú távú adatmegőrzési szabályzatokat is. A migrálás előtti biztonsági mentés visszaállítása az adatbázis biztonsági mentési megőrzési időszakán belül támogatott, a parancssoron keresztül. Ezeket a biztonsági másolatokat bármely nem rugalmas skálázású szolgáltatási szintre visszaállíthatja. |
| Adatbázisok migrálása In-Memory OLTP-objektumokkal | A Hyperscale a In-Memory OLTP-objektumok egy részét támogatja, beleértve a memóriaoptimalizált tábla típusokat, a táblaváltozókat és a natívan fordított modulokat. Ha azonban minden In-Memory OLTP-objektum jelen van a migrált adatbázisban, a Prémium és az Üzleti szempontból kritikus szolgáltatási szintekről a Rugalmas skálázásra történő migrálás nem támogatott. Ha egy ilyen adatbázist rugalmas skálázásba szeretne migrálni, minden In-Memory OLTP-objektumot és azok függőségeit el kell dobni. Az adatbázis migrálása után ezek az objektumok újra létrehozhatók. A tartós és nem tartós memóriaoptimalizált táblák jelenleg nem támogatottak a rugalmas skálázásban, ezért lemeztáblákra kell módosítani. |
| Adatbázis-integritás ellenőrzése | A DBCC CHECKDB jelenleg nem támogatott a rugalmas skálázású adatbázisok esetében. A `DBCC CHECKTABLE ('TableName') WITH TABLOCK` és a `DBCC CHECKFILEGROUP WITH TABLOCK` kerülő megoldásként használható. Az Azure SQL adatbázis adatintegritás-kezelésével kapcsolatos részletekért lásd a Adatintegritás az Azure SQL Adatbázisban szakaszt. |
| Rugalmas feladatok | Nem támogatott a rugalmas skálázású adatbázis használata feladatadatbázisként. A rugalmas feladatok azonban ugyanúgy célozhatják meg a rugalmas skálázású adatbázisokat, mint az Azure SQL Database bármely más adatbázisát. |
| Adatszinkronizálás | A rugalmas skálázású adatbázisok központi vagy metaadat-szinkronizálási adatbázisként való használata nem támogatott. Azonban egy Hyperscale adatbázis lehet tagadatbázis egy adatszinkronizálási topológiában. |
| Hiperskálázható szolgáltatási szint prémium sorozatú hardver | A prémium sorozatú és memóriaoptimalizált prémium sorozatú hardverek jelenleg nem támogatják a kiszolgáló nélküli számítási szintet. |
| Regionális rendelkezésre állás | A prémium sorozatú rugalmas skálázási szolgáltatási szint és a prémium sorozatú memóriaoptimalizált hardverek korlátozott Azure-régiókban érhetők el. A listát megtalálja a ‘Prémium Sorozatú Hiperskaláris Elérhetőség’alatti bejegyzésben. |
Kapcsolódó tartalom
- Gyakori kérdések a Hyperscale kapcsán
- Az Azure SQL Database virtuális mag- és DTU-alapú vásárlási modelljeinek összehasonlítása
- Erőforrás-kezelés az Azure SQL Database
- A vCore vásárlási modellt használó egyetlen adatbázis erőforráskorlátai
- Funkciók összehasonlítása: Azure SQL Database és Azure SQL Kezelt Példány
- rugalmas skálázású elosztott függvények architektúrája
- Rugalmas skálázású adatbázisok kezelése