Azure SQL Database rugalmas skálázás – gyakori kérdések

A következőkre vonatkozik:Azure SQL Database

Ez a cikk választ ad azoknak a gyakori kérdéseknek, amelyek az Azure SQL Database Hyperscale szolgáltatási rétegén belüli adatbázis iránt érdeklődő ügyfeleket foglalkoztatják, és amelyet a továbbiakban csak Hyperscale-ként említünk. Ez a cikk a rugalmas skálázás által támogatott forgatókönyveket és a rugalmas skálázással kompatibilis funkciókat ismerteti.

• Ez a GYIK azon olvasók számára készült, akik rövid ismeretekkel rendelkeznek a Hyperscale szolgáltatási szintről, és szeretnék, ha a konkrét kérdéseik és aggályaik meg lennének válaszolva.
• Ez a gyakori kérdések nem útmutatók, és nem válaszolnak a rugalmas skálázású adatbázisok használatára vonatkozó kérdésekre. A rugalmas skálázásról Azure SQL Database rugalmas skálázásicímű cikkben olvashat.

Általános kérdések

Mi az a rugalmas skálázású adatbázis?

A Hyperscale adatbázis olyan adatbázis az Azure SQL Database-ben, amelyet a Hyperscale skálázású tárolási technológia támogat. A rugalmas skálázású adatbázisok legfeljebb 128 TB-os adatot támogatnak, és magas átviteli sebességet és teljesítményt, valamint gyors skálázást biztosítanak a számítási feladatok követelményeinek megfelelően. A kapcsolat, a lekérdezésfeldolgozás, az adatbázismotor funkciói és így tovább, úgy működnek, mint az Azure SQL Database bármely más adatbázisában.

Milyen számítási szintek és vásárlási modellek támogatják a rugalmas skálázást?

A Hyperscale szolgáltatási szint elérhető egyes adatbázisokhoz (mind kiépített, mind kiszolgáló nélküli) és elastic poolokhoz a vCore-alapú vásárlási modell használatával. A DTU-alapú vásárlási modellben nem érhető el.

Miben különbözik a rugalmas skálázási szolgáltatási szint az általános célú és az üzleti szempontból kritikus szolgáltatási szinttől?

A virtuális magalapú szolgáltatási szintek megkülönböztethetők az adatbázis rendelkezésre állása, tárolási típusa, teljesítménye és maximális tárterülete alapján, ahogyan azt az erőforráskorlátok összehasonlítása leírja.

Ki használja a rugalmas skálázású szolgáltatási szintet?

A rugalmas skálázási szolgáltatási szint minden olyan ügyfél számára érhető el, aki nagyobb teljesítményt és rendelkezésre állást, gyors biztonsági mentést és visszaállítást, gyors tárolást és számítási méretezhetőséget keres. Ide tartoznak a kis és növekvő ügyfelek, a nagy, kritikus fontosságú adatbázisokat futtató ügyfelek, a felhőbe költöző ügyfelek, az alkalmazások és az Azure SQL Database-ben már más szolgáltatási szinteket használó ügyfelek.

A Hyperscale-val a következőket érheti el:

• Az adatbázis mérete 10 GB-ról 128 TB-ra nőhet, függetlenül a számítási mérettől.
• Virtuális mag erőforrásainak kiszámítása 2 virtuális magtól 192 virtuális magig.
• Gyors adatbázis-biztonsági mentések az adatbázis méretétől függetlenül (a biztonsági mentések a tárolási pillanatképeken alapulnak).
• Az adatbázis méretétől függetlenül gyors adatbázis-visszaállítások (a visszaállítások a tárolási pillanatképekből származnak).
• Nagyobb tranzakciónapló-átviteli sebesség az adatbázis méretétől és a virtuális magok számától függetlenül.
• Olvasási skálázás felfelé egy vagy több olvasásra szánt replikákkal, amelyeket írásvédett számítási feladatok áthelyezésére vagy meleg készenléti adatbázisokként használnak.
• A számítási kapacitás gyors felskálázása konstans idő alatt, hogy nagyobb teljesítményű legyen a nagy terhelés kezeléséhez, majd a kapacitás leskálázása konstans idő alatt. A skálázási műveletek egyjegyű perceket vesznek igénybe a kiépített számításhoz, a kiszolgáló nélküli számításhoz pedig kevesebb mint egy másodpercet, függetlenül az adatbázis méretétől.
• A kiszolgáló nélküli számítással használt adatokért való fizetés lehetősége, ahol a számítás számlázása a használat alapján történik.

Jelenleg mely régiók támogatják a rugalmas skálázást?

A rugalmas skálázási szolgáltatási szint minden olyan régióban elérhető, ahol az Azure SQL Database elérhető.

Létrehozhatok kiszolgálónként több rugalmas skálázású adatbázist?

Igen. A kiszolgálónkénti adatbázisok számával kapcsolatos további információkért és korlátozásokért tekintse meg kiszolgálóiönálló és készletezett adatbázisok SQL Database-erőforráskorlátait.

Mik a rugalmas skálázású adatbázisok teljesítményjellemzői?

A rugalmas skálázási architektúra nagy teljesítményt és átviteli sebességet biztosít, miközben támogatja a nagy méretű adatbázisokat.

Mi a rugalmas skálázású adatbázisok méretezhetősége?

A rugalmas skálázás gyors méretezhetőséget biztosít a számítási feladatok igényeinek megfelelően.

• fel- és leskálázás

  A rugalmas skálázással az elsődleges számítási méretet vertikálisan felskálázhatja az erőforrások, például a processzor és a memória tekintetében, majd folyamatosan leskálázhatja a méretet. Mivel a tárolás távoli, a felméretezés és lekicsinyítés nem adatméret-művelet.

  A kiszolgáló nélküli számítás támogatása automatikus felskálázást, leskálázást és számítási költségek számlázását biztosít a használat alapján.

• skálázás be/kimenet

  A Hyperscale szolgáltatással háromféle másodlagos replika használható az olvasási kapacitás növeléséhez, a magas rendelkezésre állás biztosításához és a földrajzi replikációs követelmények kielégítéséhez. Ez a következőket foglalja magában:

  • Legfeljebb négy magas rendelkezésre állású replika ugyanazzal a számítási méretel, mint az elsődleges. Ezek gyors készenléti replikaként szolgálnak az elsődleges feladatátvételhez. Használhatja őket az olvasási műveletek elsődleges rendszerről való tehermentesítésére is.
  • Legfeljebb 30 elnevezett replika, amelyek az elsődlegesnél azonos vagy eltérő számítóméterrel rendelkeznek, hogy különböző olvasási felskálázási forgatókönyveket támogassanak.
  • Egy georeplika egy másik Azure-régióban a regionális kimaradások elleni védelemhez és a földrajzi olvasási felskálázás engedélyezéséhez.

Mélyreható kérdések

Keverhetem a rugalmas skálázású és a nem rugalmas skálázású adatbázisokat ugyanazon az SQL logikai kiszolgálón?

Igen, megteheted.

A rugalmas skálázás megköveteli az alkalmazásprogramozási modell módosítását?

Nem, az alkalmazásprogramozási modell ugyanaz marad, mint bármely más MSSQL-adatbázis esetében. A kapcsolati karakterláncot a szokásos módon használja, és szokásos módon lép kölcsönhatásba a Hyperscale adatbázissal. Miután az alkalmazás a rugalmas skálázású adatbázist használja, az alkalmazás kihasználhatja az olyan funkciók előnyeit, mint például másodlagos replikák.

Melyik tranzakcióelkülönítési szint az alapértelmezett a rugalmas skálázású adatbázisokban?

Az elsődleges replikán az alapértelmezett tranzakcióelkülönítési szint READ COMMITTED, az READ_COMMITTED_SNAPSHOT adatbázis-beállítás (RCSI) engedélyezése mellett. A másodlagos replikák elkülönítési szintje SNAPSHOT. Ez ugyanaz, mint bármely más Azure SQL-adatbázisban.

Vihetem a helyszíni vagy az IaaS SQL Server-licencemet a Hyperscale-be?

Az új, egyszerűsített díjszabás 2023. december 15. óta érvényes, így az újonnan létrehozott rugalmas skálázású adatbázisok, a kiszolgáló nélküli rugalmas skálázású adatbázisok és az összes rugalmas skálázású készlet számítási ára csökkent. Az új, egyszerűsített díjszabással nem szükséges az Azure Hybrid Benefit (AHB) alkalmazása az ezzel egyenértékű megtakarítás eléréséhez. Az Azure Hybrid Benefit (AHB) csak régebbi (2023. december 15. előtt létrehozott) rugalmas skálázású önálló adatbázisokra alkalmazható kiépített számítással. A régebbi adatbázisok esetében az AHB csak 2026 decemberéig alkalmazható, amely után az adatbázisok számlázása is az új, egyszerűsített díjszabás szerint történik.

További információ: Rugalmas skálázási díjszabás blog és Azure SQL Database Rugalmas skálázás – alacsonyabb, egyszerűsített díjszabási.

Milyen típusú munkaterhelésekhez készült a Hyperscale?

A rugalmas skálázás minden számítási feladattípushoz jól működik, beleértve az OLTP, a hibrid (HTAP) és az elemzési (adatbővítő) számítási feladatokat.

Hogyan választhatok az Azure Synapse Analytics és az Azure SQL Database rugalmas skálázása között?

Ha jelenleg interaktív elemzési lekérdezéseket futtat az SQL Server adattárházként való használatával, a rugalmas skálázás nagyszerű lehetőség, mivel kisebb és közepes méretű adattárházakat (például néhány TB-ot akár 128 TB-ot) is üzemeltethet alacsonyabb költséggel, és minimális T-SQL-kódmódosításokkal migrálhatja az SQL Server-adattárház számítási feladatait rugalmas skálázásba.

Ha nagy léptékű adatelemzést futtat összetett lekérdezésekkel és 100 MiB/s-nél magasabb tartós betöltési arányokkal, vagy párhuzamos adattárház (PDW), Teradata vagy más nagymértékben párhuzamos feldolgozási (MPP) adattárházak, például az Azure Synapse Analytics használatával, akkor a Microsoft Fabric lehet a legjobb választás.

A betöltési vagy naplógenerálási arány adatbázisonként 150 MiB/s az Azure SQL Database hiperskálázású prémium sorozatú és prémium memóriaoptimalizált hardverén. Standard sorozatú hardverek esetén a maximális naplósebesség adatbázisonként 100 MiB/s. Rugalmas készletek esetén a maximális naplózási sebesség készletenként 150 MiB/s a prémium sorozatú és prémium sorozatú memóriaoptimalizált hardverek esetében, valamint készletenként 125 MiB/s a többi hardver esetében.

Rugalmas skálázású számítási kérdések

Bármikor szüneteltethetem a számításomat?

Jelenleg nem. A számítási kapacitást és a replikák számát azonban csökkentheti, hogy csökkentse a költségeket a nem csúcsidőszakban, vagy a serverless használatával automatikusan skálázhatja a számítási kapacitást a használat függvényében.

Kiépíthetik egy számítási replikát extra RAM-mal a memóriaigényes számítási feladatokhoz?

Olvasási számítási feladatokhoz létrehozhat egy nevű replikát, nagyobb számítási mérettel (több maggal és memóriával) rendelkezik, mint az elsődleges. A rendelkezésre álló számítási méretekről további információt Rugalmas skálázású tárterület és számítási méretekcímű témakörben talál.

Kiépíthetek különböző méretű, több számítástechnikai replikát?

Olvasási számítási feladatok esetében ez elnevezett replikákhasználatával érhető el.

Hány olvasási méretezhetőségi replikát támogatnak?

A másodlagos HA-replikák számát 0 és 4 között skálázhatja az Azure Portal vagy REST APIhasználatával. Emellett akár 30 elnevezett replikát is létrehozhat sok olvasási skálázási esethez. Minden elnevezett replika legfeljebb 4 másodlagos HA replikával rendelkezhet.

A magas rendelkezésre állás érdekében ki kell építenem további számítási replikákat?

Rugalmas skálázású adatbázisokban az adatrugalmasság a tárolási szinten biztosított. A rugalmasság biztosításához csak egy replikára (az elsődleges) van szüksége. Ha a számítási replika meghibásodik vagy karbantartás alatt áll, a rendszer automatikusan létrehoz egy új replikát adatvesztés nélkül.

Ha azonban csak az elsődleges replika található, egy-két percig is eltarthat egy új replika létrehozása, szemben másodpercekkel abban az esetben, ha egy másodlagos HA-replika érhető el. Az új replika kezdetben hideg gyorsítótárakat fog tartalmazni, ami nagyobb tárolási késést és kevesebb lekérdezési teljesítményt eredményezhet közvetlenül a feladatátvétel után.

Az olyan kritikus fontosságú alkalmazások esetében, amelyek minimális feladatátvételi hatással járó magas rendelkezésre állást igényelnek, legalább egy másodlagos HA-replikát ki kell építenie, hogy a gyakori készenléti replika rendelkezésre álljon feladatátvételi célként.

Adatméretre és tárolásra vonatkozó kérdések

Mi a rugalmas skálázás által támogatott maximális adatbázisméret?

Egy rugalmas skálázású adatbázis maximális mérete jelenleg 128 TB, a számítási mérettől függetlenül. A Hyperscale rugalmas készletben egy adatbázis maximális mérete jelenleg 100 TB.

Mi a tranzakciónapló mérete a Hyperscale technológiával?

Rugalmas skálázás esetén a tranzakciónapló gyakorlatilag végtelen, azzal a korlátozással, hogy a napló aktív része nem haladhatja meg az 1 TB-ot. A napló aktív része a hosszú ideig futó tranzakciók miatt növekedhet, vagy Adatrögzítés módosítása feldolgozás nem tartja lépést az adatváltozás sebességével. Kerülje a szükségtelenül hosszú és nagy tranzakciókat, hogy a korlát alatt maradjon. A korlátozáson kívül nem kell aggódnia amiatt, hogy elfogy a naplóterület egy olyan rendszeren, amely magas naplózási átviteli sebességgel rendelkezik. A naplók előállítási aránya azonban csökkenthető a folyamatos nagy intenzitású írási feladatok esetében. A naplógenerálási arány 150 MiB/s a prémium sorozatú és prémium sorozatú memóriaoptimalizált hardverekhez, valamint 100 MiB/s más hardverekhez.

Az adatbázisom növekedésével együtt skálázódik a tempdb?

A tempdb adatbázis a helyi SSD-tárolóban található, és a kiépített számítási méret (a magok száma) arányában van méretezve. A(z) tempdb mérete nem konfigurálható, és automatikusan van kezelve Önnek. Az adatbázis maximális tempdb méretének meghatározásához tekintse meg rugalmas skálázású tároló- és számítási méreteket.

Automatikusan nő az adatbázis mérete, vagy kezelni kell az adatfájlok méretét?

Az adatbázis mérete automatikusan nő a további adatok beszúrása/betöltésekor.

Mi a rugalmas skálázás által támogatott legkisebb adatbázisméret?

10 GB. A rugalmas skálázású adatbázis 10 GB kezdőmérettel jön létre, és igény szerint növekszik.

Milyen lépésekben nő az adatbázis mérete?

Minden adatfájl 10 GB-kal nő. Egyszerre több adatfájl is növekedhet.

Helyi vagy távoli a Hyperscale tárolás?

Rugalmas skálázás esetén az adatfájlok tárolása az Azure Standard Storage-ban történik. Az adatok teljes mértékben gyorsítótárazva vannak a helyi SSD-tárolóban, a számítási replikáktól távoli lapkiszolgálókon. Emellett a számítási replikák adatgyorsítótárakat is tárolnak a helyi SSD-n és a memóriában, hogy csökkenjen az adatok távoli lapkiszolgálókról való lekérésének gyakorisága.

Használhatom vagy megadhatom a fájlokat vagy fájlcsoportokat Hyperscale technológiával?

Nem. A rendszer automatikusan hozzáadja az adatfájlokat a PRIMARY fájlcsoporthoz. A további fájlcsoportok létrehozásának gyakori okai nem alkalmazhatók a rugalmas skálázású tárolóarchitektúrában vagy az Azure SQL Database-ben.

Kiépíthetik egy szigorú korlátot az adatbázis adatnövekedésére?

Nem.

Támogatott az adatbázis zsugorítása?

Igen, adatbázis- és fájlzsugorítási műveletek támogatottak az Azure SQL Database rugalmas skálázásában.

Támogatott az adattömörítés?

Igen, csakúgy, mint bármely más Azure SQL DB-adatbázisban. Ide tartoznak a sor-, oldal- és oszlop.

Ha hatalmas táblázatom van, a táblaadatok több adatfájl között oszlanak el?

Igen. Az adott táblához társított adatlapok több adatfájlba is tartozhatnak, amelyek mind ugyanahhoz a fájlcsoporthoz tartoznak. Az MSSQL adatbázismotor arányos kitöltési stratégiát az adatok adatfájlokon keresztüli elosztásához.

Adatmigrálással kapcsolatos kérdések

Áthelyezhetem az Azure SQL Database-ben lévő meglévő adatbázisaimat a rugalmas skálázású szolgáltatási szintre?

Igen. A koncepcióigazolások (POC-k) esetében javasoljuk, hogy készítsen másolatot az adatbázisról, és migrálja a másolatot Hyperscale-re.

A meglévő adatbázisok rugalmas skálázásba való áthelyezéséhez szükséges idő az adatok másolásának ideje, valamint a forrásadatbázisban végrehajtott módosítások visszajátszásának ideje az adatok másolása során. Az adatmásolási idő arányos az adatméretével. A módosítások visszajátszásának ideje rövidebb, ha az áthelyezés alacsony írási tevékenység időszakában történik.

Meglévő Azure SQL Database-adatbázist rugalmas skálázásúvá alakíthat az Azure Portalon, az Azure CLI-ben, a PowerShellben és a Transact-SQL-ben. További információ: Az adatbázis átalakítása hiperskálázhatóvá.

Fordított migrálás az Általános célú szolgáltatási szintre lehetővé teszi, hogy azok az ügyfelek, akik nemrég migráltak egy meglévő adatbázist az Azure SQL Database-ben a Hyperscale szolgáltatási szintre, visszaléphessenek, ha a Hyperscale nem felel meg az igényeiknek. Bár a fordított migrálást egy szolgáltatási szint módosítása kezdeményezi, ez lényegében egy adatméret-művelet a különböző architektúrák között. A rugalmas skálázásra való migráláshoz hasonlóan a fordított migrálás is gyorsabb, ha alacsony írási tevékenység alatt történik. További információért lásd: Hyperscale-ből való visszamigrálás.

Áthelyezhetem a rugalmas skálázású adatbázisaimat más szolgáltatási szintekre?

Ha korábban már migrált egy meglévő Azure SQL Database-adatbázist a rugalmas skálázási szolgáltatási szintre, az eredeti rugalmas skálázásra való migrálást követő 45 napon belül visszatelepítheti azt 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 térjen vissza az Általános célú szolgáltatási szintre, majd módosítsa a szolgáltatási szintet. A fordított migrálás adatméretű művelet.

A rugalmas skálázású szolgáltatási szinten létrehozott adatbázisok nem helyezhetők át más szolgáltatási szintekre.

Ismerje meg, hogyan fordíthatja vissza a migrálást a Hyperscale-ből, beleértve a fordított migrálás korlátozásait és a biztonsági mentési szabályzatokat.

Elveszítek bármilyen funkciót vagy képességet a rugalmas skálázású szolgáltatási szintre való migrálás után?

Igen. Az Azure SQL Database egyes funkciói nem támogatottak a rugalmas skálázásban. Ha ezen funkciók némelyike engedélyezve van az adatbázishoz, a rugalmas skálázásra való migrálás blokkolható, vagy ezek a funkciók az áttelepítés után leállnak. További információ: Ismert korlátozások.

Áthelyezhetem a helyszíni SQL Server adatbázisomat, vagy a felhőbeli virtuális gépen lévő SQL Server adatbázisomat a Hyperscale-re?

Igen. Számos meglévő migrálási technológiát használhat a rugalmas skálázásba való migráláshoz, beleértve a tranzakciós replikációt és bármely más adatátviteli technológiát (tömeges másolás, Azure Data Factory, Azure Databricks, SSIS). Lásd még a Azure Database Migration Service, amely számos migrálási forgatókönyvet támogat.

Mi az állásidőm a helyszíni vagy virtuális gép környezetből a Hyperscale-be való migrálás során, és hogyan minimalizálhatom?

A Hyperscale-re történő migrálás állásideje megegyezik az adatbázisok más Azure SQL Database-szolgáltatási szintekre történő migrálásának állásidejével. A tranzakciós replikáció használatával minimalizálhatja az állásidőt a néhány TB méretű adatbázisok migrálása során. Nagyon nagy adatbázisok (10+ TB) esetén megfontolhatja a migrálási folyamat implementálását az ADF, a Spark vagy más tömeges adatáthelyezési technológiák használatával.

Mennyi időt vesz igénybe x mennyiségű adat betöltése a Hyperscale-be?

A rugalmas skálázás legfeljebb 150 MiB/s új/módosított adatot képes felhasználni, de az Azure SQL Database adatbázisaiba való áthelyezéshez szükséges időt a rendelkezésre álló hálózati átviteli sebesség, a forrásolvasási sebesség, a terhelés típusa (tömeges és sorról sorra) és a céladatbázis szolgáltatásiszint-célkitűzése is befolyásolja.

Olvashatok adatokat a Blob Storage-ból, és gyorsan betölthetem őket (például a Polybase-et az Azure Synapse Analyticsben)?

Az ügyfélalkalmazás adatokat olvashat be az Azure Storage-ból, és betöltheti az adatokat egy rugalmas skálázású adatbázisba (ugyanúgy, mint bármely más Azure SQL Database-adatbázis esetében). A Polybase jelenleg nem támogatott az Azure SQL Database-ben. A gyors terhelés alternatívaként használja az Azure Data Factoryt.

Az Adatok tömeges beolvasása az Azure Blob Store-ból a BULK INSERT vagy az OPENROWSET használatával is lehetséges: Példák az Adatok tömeges elérésére az Azure Blob Storage-ban.

Az egyszerű vagy csoportos naplózott helyreállítási modellek nem támogatottak Hyperscale-ban. A magas rendelkezésre állás és az időponthoz kötött helyreállítás biztosításához teljes helyreállítási modell szükséges. A rugalmas skálázású naplóarchitektúra azonban jobb adatbetöltési sebességet biztosít a többi Azure SQL Database-szolgáltatási szinthez képest.

A rugalmas skálázás lehetővé teszi több csomópont kiépítését nagy mennyiségű adat párhuzamos betöltéséhez?

Nem. A Hyperscale szimmetrikus többfeldolgozós (SMP) architektúra, nem pedig nagymértékben párhuzamos feldolgozás (MPP) vagy többmester-architektúra. Több replikát is létrehozhat a csak olvasható feladatok horizontális felskálázásához.

Támogatja a rugalmas skálázás más adatforrásokból, például az Amazon Aurora, a MySQL, a PostgreSQL, az Oracle, a DB2 és más adatbázisplatformokból való migrálást?

Igen. Azure Database Migration Service számos migrálási forgatókönyvet támogat.

Amikor rugalmas skálázásra konvertálok egy adatbázist, mikor kezdődik a rugalmas skálázás számlázása?

A rugalmas skálázású számlázás az átalakítás után csak az átállás befejezése után kezdődik.

Amikor Hyperscale-re váltok, lehetőségem van-e az adatbázisom zavarainak kezelésére?

Igen. Az átalakítás indításakor megadhatja az átállás jellegét. A folyamat automatikus lehet, amint készen áll, vagy manuálisan is elindítható, amikor készen áll. További információ: Adatbázis konvertálása rugalmas skálázásra. Az átállást manuálisan is kezdeményezheti az Azure Portalon, a PowerShellen, az Azure CLI-en vagy a T-SQL-en keresztül. Az Hyperscale-re való végleges átállás során csak rövid, általában egy percnél rövidebb állásidőt fog tapasztalni.

Üzletmenet-folytonossági és vészhelyreállítási kérdések

Milyen SLA-k érhetők el a rugalmas skálázású adatbázisokhoz?

Lásd Azure SQL DatabaseSLA-ját. Javasoljuk, hogy adjon hozzá másodlagos HA-replikákat a kritikus munkaterhelésekhez. Ez gyorsabb feladatátvételt biztosít, és közvetlenül a feladatátvétel után csökkenti a lehetséges teljesítményhatást.

Az adatbázis biztonsági mentéseit az Azure SQL Database felügyeli?

Igen.

Támogatja a rugalmas skálázás a rendelkezésre állási zónákat?

Igen, a Hyperscale támogatja a zónaredundáns konfiguráció-t. A Hyperscale számára a zónaredundáns konfiguráció engedélyezéséhez legalább egy másodlagos HA-replika, valamint zónaredundáns vagy geozónaredundáns tároló szükséges.

A Hyperscale támogatja a rugalmas készleteket?

Igen. További információ: Rugalmas rugalmas készletek és Blog: A rugalmas rugalmas készletek mostantól általánosan elérhetők.

Milyen gyakran készül adatbázis-biztonsági mentés?

A Hyperscale adatbázisokhoz nincsenek hagyományos teljes, különbségi és tranzakciónapló-biztonsági mentések. Ehelyett az adatfájlok rendszeres tárolási pillanatképei vannak, és mindegyik fájlhoz külön pillanatkép-ütemezés tartozik. A létrehozott tranzakciónapló a konfigurált megőrzési időszak alatt változatlan formában marad. A visszaállításkor a rendszer a megfelelő tranzakciónapló-rekordokat alkalmazza a visszaállított tárolási pillanatképekre. A pillanatképek gyakoriságától függetlenül ez egy tranzakciós konzisztens adatbázist eredményez a megőrzési időszakon belül megadott időponttól kezdve, adatvesztés nélkül. A Hyperscale adatbázis biztonsági mentése folyamatos.

Támogatja a Hyperscale az időponthoz kötött visszaállítást?

Igen.

Mi a helyreállítási pont célkitűzése (RPO)/Helyreállítási idő célkitűzése (RTO) a rugalmas skálázású adatbázis-visszaállításhoz?

Az időponthoz kötött visszaállítás RPO-jának időtartama 0 perc. A legtöbb időponthoz kötött visszaállítási művelet az adatbázis méretétől függetlenül 60 percen belül befejeződik. A visszaállítási idő hosszabb lehet a nagyobb adatbázisok esetében, és ha az adatbázis jelentős írási tevékenységet tapasztalt a visszaállítási időpontig. A tárterület-redundancia legutóbbi módosítása után a visszaállítási hosszabb visszaállítási időt eredményezhet, mivel ebben az esetben a visszaállítás adatméretű művelet lehet, és a visszaállítási idő arányos lehet az adatbázis méretével.

Befolyásolja az adatbázis biztonsági mentése az elsődleges vagy másodlagos replikák számítási teljesítményét?

Nem. A biztonsági mentéseket a tárolási alrendszer felügyeli, és tárolási pillanatképeket használ. Ezek nem befolyásolják a felhasználói számítási feladatokat.

Végezhetek georeduktív visszaállítást rugalmas skálázású adatbázissal?

Igen. Geo-helyreállítás teljes mértékben támogatott, ha georedundáns vagy geo-zónaredundáns tárolást használnak. Az új adatbázisok esetében a georedundáns tárolás az alapértelmezett. Az időpillanat alapú visszaállításhoz képest a geovisszaállítás adatméret-műveletet igényel. Az adatfájlok párhuzamos másolása így a művelet időtartama elsősorban az adatbázis legnagyobb fájljának méretétől függ, nem pedig az adatbázis teljes méretétől. A georedundáns visszaállítási idő jelentősen rövidebb, ha az adatbázis a forrásadatbázis régiójával párosított Azure-régióban van visszaállítva . További információkért lásd: Az Azure SQL Databasegeo-visszaállítása.

Beállíthatok georeplikációs vagy feladatátvételi csoportokat rugalmas skálázású adatbázissal?

Igen. georeplikációs és feladatátvételi csoportok beállíthatók rugalmas skálázású adatbázisokhoz.

Készíthetek egy rugalmas skálázású adatbázis biztonsági mentését, és visszaállíthatom a helyszíni kiszolgálóra, vagy egy virtuális gépen lévő SQL Serverre?

Nem. A rugalmas skálázású adatbázisok tárolási formátuma eltér az SQL Server bármely kiadott verziójától, és nem szabályozza a biztonsági mentéseket, és nem rendelkezik hozzáféréssel hozzájuk. Ha adatokat szeretne kinyerni egy rugalmas skálázású adatbázisból, bármilyen adatáthelyezési technológiával kinyerheti az adatokat, például az Azure Data Factoryt, az Azure Databrickset, az SSIS-t stb.

Fel lesz számítva díj a Hyperscale biztonsági mentési tárhelyének költségeiért?

Igen. 2022. május 4-én az összes új adatbázis biztonsági mentését a felhasznált biztonsági mentési tárterület és a kiválasztott tárterület-redundancia alapján számítjuk fel az Azure SQL Database díjszabási oldalán . A 2022. május 4. előtt létrehozott rugalmas skálázású adatbázisok esetében a biztonsági mentések csak akkor kerülnek felszámításra, ha a biztonsági másolatok megőrzési ideje hét napnál hosszabb. További információ: rugalmas skálázású biztonsági mentések és tárolóredundancia.

Hogyan mérhetem meg a biztonsági mentési tár méretét a rugalmas skálázású adatbázisban?

A biztonsági másolatok tárolási méretének méréséről további információt Automatikus biztonsági mentésekcímű témakörben talál.

Honnan tudhatom, hogy mi lesz a biztonsági mentési számlám?

A biztonsági mentési tárterület díjának meghatározásához a biztonsági mentési tárterület méretét rendszeres időközönként számítjuk ki, és megszorozzuk a biztonsági mentés tárolási sebességével és az utolsó számítás óta eltelt órák számával. A biztonsági mentési számla időszakonkénti becsléséhez szorozza meg az időszak minden órájára vonatkozó számlázható biztonsági mentési tárterület méretét a biztonsági mentés tárolási sebességével, és adja hozzá az összes óránkénti összeget. A releváns Azure Monitor-metrikák programozott módon történő lekérdezéséhez használja az Azure Monitor REST API. A kiszolgáló nélküli számítási szint biztonsági mentésének számlázása megegyezik a kiépített számítási szint számlázásával.

Hogyan befolyásolja a számítási feladat a biztonsági mentés tárolási költségeit?

A biztonsági mentési költségek magasabbak az olyan számítási feladatok esetében, amelyek nagy mennyiségű adatot adnak hozzá, módosítanak vagy törölnek az adatbázisban. Ezzel szemben a többnyire írásvédett számítási feladatok alacsonyabb biztonsági mentési költségekkel járhatnak.

Hogyan minimalizálhatom a biztonsági mentés tárolási költségeit?

A biztonsági mentés tárolási költségeinek minimalizálásáról további információt Automatikus biztonsági mentésekcímű témakörben talál.

Georeduktívan visszaállíthatom a rugalmas skálázású adatbázist egy másik szolgáltatási szintre, vagy fordítva?

Jelenleg a nem rugalmas skálázású szolgáltatási szintek (Alapszintű/Standard/Prémium/Általános célú/Üzleti szempontból kritikus) biztonsági másolatok nem állíthatók vissza georeduktívan rugalmas skálázású szolgáltatási szintre, és fordítva. Ha nem rugalmas skálázású adatbázist szeretne rugalmas skálázású adatbázissá alakítani, módosítsa a szolgáltatási szintet a visszaállítás után.

Teljesítménnyel kapcsolatos kérdések

Mennyi írási átviteli sebességet tudok leküldni egy rugalmas skálázású adatbázisban?

A tranzakciónapló átviteli korlátja 100 MiB/s bármilyen Hyperscale számítási mérethez. A sebesség elérésének lehetősége több tényezőtől függ, többek között a számítási feladatok típusától, az ügyfélkonfigurációtól és a teljesítménytől, és az elsődleges számítási replikán elegendő számítási kapacitással rendelkezik a naplórekordok ilyen sebességgel történő létrehozásához. A betöltési vagy naplógenerálási arány adatbázisonként 150 MiB/s az Azure SQL Database hiperskálázású prémium sorozatú és prémium memóriaoptimalizált hardverén. Standard sorozatú hardverek esetén a maximális naplósebesség adatbázisonként 100 MiB/s. Rugalmas készletek esetén a maximális naplózási sebesség készletenként 150 MiB/s a prémium sorozatú és prémium sorozatú memóriaoptimalizált hardverek esetében, valamint készletenként 125 MiB/s a többi hardver esetében.

Hány IOPS-t kapok a legnagyobb számítási erőforráson?

Az IOPS és az IO késése a számítási feladatok mintáitól függően változik. Ha a hozzáférő adatok gyorsítótárazva lesznek a számítási replika helyi SSD-tárolójában, hasonló IO-teljesítményt fog látni, mint az üzletileg kritikus vagy prémium szolgáltatási szinteken.

Hatással van az átviteli sebességemre a biztonsági másolatok?

Nem. A számítás leválasztva van a tárolási rétegről. Ez kiküszöböli a biztonsági mentés teljesítményre gyakorolt hatását.

Hatással van az átviteli sebességemre, amikor további számítási replikákat építek ki?

Mivel a tároló meg van osztva, és nem történik közvetlen fizikai replikáció az elsődleges és a másodlagos számítási replikák között, az elsődleges replika átviteli sebességét nem befolyásolja közvetlenül másodlagos replikák hozzáadása. A folyamatos és agresszív írási feladatok naplósebessége azonban korlátozott lehet az elsődlegesnél, hogy lehetővé tegye a napló alkalmazását a másodlagos replikákon és a lapkiszolgálókon, hogy azok felzárkózzanak. Ez elkerüli a másodlagos replikák gyenge olvasási teljesítményét és a hosszú helyreállítást a HA másodlagos replikára történő feladatátvétel után.

Alkalmas a Hyperscale erőforrás-igényes, hosszú ideig futó lekérdezésekhez és tranzakciókhoz?

Igen. A többi Azure SQL-adatbázishoz hasonlóan azonban előfordulhat, hogy a kapcsolatok nagyon ritkán átmeneti hibákkal végződnek, amelyek megszakíthatják a hosszú ideig futó lekérdezéseket és visszaállíthatják a tranzakciókat. Az átmeneti hibák egyik oka, hogy a rendszer gyorsan áthelyezi az adatbázist egy másik számítási csomópontra, hogy biztosítsa a számítási és tárolási erőforrások folyamatos rendelkezésre állását, vagy tervezett karbantartást végezzen. Az újrakonfigurálási események többsége kevesebb mint 10 másodperc alatt fejeződik be. Az adatbázishoz csatlakozó alkalmazásokat úgy kell létrehozni, hogy az újrapróbálkozási logika implementálásával elvárják és tolerálják ezeket a ritkán előforduló átmeneti hibákat. Emellett érdemes lehet konfigurálni egy karbantartási időszak, amely megfelel a számítási feladatok ütemezésének, hogy elkerülje a tervezett karbantartás miatti átmeneti hibákat.

Hogyan diagnosztizálhatom és háríthatom el a teljesítményproblémákat egy rugalmas skálázású adatbázisban?

A legtöbb teljesítményproblémára, különösen a tárolási teljesítményben gyökerező problémákra az MSSQL gyakori diagnosztikai és hibaelhárítási lépései érvényesek. A Hyperscale-specifikus tárolási diagnosztikával kapcsolatos információkért lásd a SQL Hyperscale teljesítmény hibaelhárítási diagnosztika című témakört.

Hogyan viszonyul a kiszolgáló nélküli memória maximális korlátja a kiépített számításhoz?

A kiszolgáló nélküli adatbázisok által felskálázható maximális memóriamennyiség 3 GB/virtuális mag a konfigurált virtuális magok maximális számának 3 GB/vCore-szorosa, szemben a kiosztott számításban lévő virtuális magok számával több mint 5 GB/virtuális magmal. Részletekért tekintse át kiszolgáló nélküli rugalmas skálázási erőforráskorlátokat.

Hogyan szolgálja a folyamatos előkészítés az ügyfeleket?

A folyamatos feltöltés segít fenntartani az RBPEX (rugalmas pufferkészletbővítmény) magasabb kihasználtságát, ami jobb teljesítményt eredményez. Biztosítja, hogy a másodlagos adatbázis mindig készen álljon a késedelem nélküli átvételre, ezáltal javítva a feladatátvételi időket és a rendszer általános megbízhatóságát.

Milyen számítási szintek támogatják a folyamatos inicializálást?

A folyamatos inicializálás a kiosztott Hyperscale számítási szint prémium sorozatú hardverén és memóriaoptimalizált prémium sorozatú hardverén érhető el. A folyamatos alapozás jelenleg nem érhető el a kiszolgáló nélküli Hyper-skálázott számítási szint esetében.

Előnyös-e a folyamatos priming a megnevezett replikák számára?

Az elnevezett replikák nem élvezik a folyamatos előkészítés előnyeit.

Méretezhetőségi kérdések

Mennyi ideig tart egy számítási replika vertikális fel- vagy leskálázása?

A kiépített számítási szint fel- vagy leskálázása általában 2 percet vesz igénybe, az adatmérettől függetlenül. A kiszolgáló nélküli számítási rétegben, ahol a számítási feladat igényeinek megfelelően automatikusan skálázódik a számítás, a skálázási idő általában alszekundum, de esetenként akár a kiépített számítás skálázása is eltarthat.

Az adatbázis offline állapotban van, miközben a fel- és leskálázási művelet folyamatban van?

Nem. Az adatbázis online állapotban marad a vertikális felskálázási vagy vertikális leskálázási műveletek során.

Számíthatok a kapcsolat megszakadására, ha a skálázási műveletek folyamatban vannak?

A kiosztott számítás fel- vagy leskálázása azt eredményezi, hogy a kapcsolatok megszakadnak, amikor feladatátvétel történik a skálázási művelet végén. A kiszolgáló nélküli számításban az automatikus skálázás általában nem eredményezi a kapcsolat megszakadását, de időnként előfordulhat. A másodlagos replikák hozzáadása vagy eltávolítása nem eredményezi a kapcsolat megszakadát az elsődlegesen.

Automatikus vagy végfelhasználó által aktivált művelet a számítási replikák fel- és leskálázása?

A kiépített számításban a skálázást a végfelhasználó végzi. A kiszolgáló nélküli számítás automatikus skálázását a szolgáltatás végzi.

A tempdb-adatbázis és a számítási SSD-gyorsítótár mérete is nő a számítás felskálázása során?

Igen. A tempdb adatbázis és számítási SSD-gyorsítótár számítási csomópontok mérete automatikusan felskálázódik a magok számának növekedésével. További információ: Rugalmas skálázású tároló és számítási méretek.

Kiépíthetek több elsődleges számítási replikát, például egy több főkiszolgálós rendszert, ahol több elsődleges számítási fej képes magasabb szintű egyidejűséget eredményezni?

Nem. Csak az elsődleges számítási replika fogad olvasási/írási kéréseket. A másodlagos számítógépes másolatok csak olvasási kérelmeket fogadnak el.

Felskálázási kérdések olvasása

Milyen másodlagos (olvasási felskálázás) replikák érhetők el a Hyperscale-ben?

A Hyperscale támogatja a magas rendelkezésre állású (HA) replikákat, a névvel ellátott replikákat és a geo-replikákat. Részletekért lásd rugalmas skálázású másodlagos replikákat.

Hány másodlagos HA-replikát helyezhetek üzembe?

0 és 4 között. Ha módosítani szeretné a replikák számát, ezt Azure Portal vagy REST APIhasználatával teheti meg.

Hogyan csatlakozhatok másodlagos HA-replikához?

Ezekhez a további írásvédett számítási replikákhoz úgy csatlakozhat, hogy a kapcsolati sztring ApplicationIntent tulajdonságát ReadOnlyértékre állítja. A ReadOnly megjelölt kapcsolatok automatikusan a másodlagos HA-replikák egyikére lesznek irányítva, ha vannak ilyenek. Részletekért lásd: Írásvédett replikák használata az írási műveletektől elkülönített lekérdezési terhelésekhez.

Hogyan ellenőrizhetem, hogy sikeresen csatlakoztam-e egy másodlagos számítási replikához az SQL Server Management Studio (SSMS) vagy más ügyféleszközök használatával?

A következő T-SQL-lekérdezést hajthatja végre: SELECT DATABASEPROPERTYEX ('<database_name>', 'Updateability'). Az eredmény READ_ONLY, ha írásvédett másodlagos replikához csatlakozik, és READ_WRITE, ha az elsődleges replikához csatlakozik. Az adatbázis-környezetet az adatbázis nevére kell állítani, nem pedig a master adatbázisra.

Létrehozhatok dedikált végpontot egy másodlagos HA-replikához?

Nem. Csak akkor csatlakozhat másodlagos replikákhoz, ha megadja a ApplicationIntent=ReadOnly. Azonban dedikált végpontokat is használhat elnevezett replikákhoz.

Végez a rendszer intelligens terheléselosztást az írásvédett feladatoknál a HA másodlagos replikákon?

Nem. A csak olvasásra szánt új kapcsolatot bármelyik HA másodlagos replikára irányít át a rendszer.

Fel- és leskálázhatom a másodlagos HA replikákat az elsődleges replikától függetlenül?

Nem az előírt számítási rétegen. A másodlagos HA-replikák magas rendelkezésre állású feladatátvételi célként szolgálnak, ezért a feladatátvétel utáni várható teljesítmény biztosításához az elsődleges konfigurációval megegyező konfigurációval kell rendelkezniük. Kiszolgáló nélküli környezetben a számítási feladat automatikusan skálázódik az egyes HA-replikákhoz az egyéni számítási feladatok igényei alapján. Minden HA másodlagos továbbra is automatikusan skálázódhat a konfigurált maximális magokra, hogy elláthassa feladatátvétel utáni szerepkörét. elnevezett replikák lehetővé teszik az egyes elnevezett replikák egymástól függetlenül történő skálázását.

Kapok más tempdb-méretezést az elsődleges számításomhoz és a másodlagos HA replikáimhoz?

Nem. A tempdb adatbázis a kiosztott számítási méret alapján van konfigurálva; a másodlagos HA-replikák mérete megegyezik az elsődleges számítás méretével, beleértve a tempdb. elnevezett replikákontempdb a replika számítási méretének megfelelően méretezhető, így kisebb vagy nagyobb lehet, mint az elsődleges tempdb.

Hozzáadhatok indexeket és nézeteket a másodlagos számítási replikáimhoz?

Nem. A rugalmas skálázású adatbázis számítási replikái osztoznak a tárolóban, ami azt jelenti, hogy minden számítási replika ugyanazokat a táblákat, indexeket és más adatbázis-objektumokat látja. Ha további indexeket szeretne optimalizálni a másodlagos olvasásokhoz, azokat hozzá kell adnia az elsődlegeshez. A másodlagos replikákon továbbra is létrehozhat ideiglenes táblákat (#vagy ##előtaggal ellátott táblaneveket), hogy ideiglenes adatokat tároljon a tempdb adatbázisban. Az ideiglenes táblák olvasási és írási lehetőséggel rendelkeznek.

Mennyi késés van az elsődleges és a másodlagos számítási replikák között?

Az adatkésés attól az időponttól kezdve, amikor egy tranzakció el van kötelezve az elsődleges rendszeren, és olvasható a másodlagos rendszeren, az aktuális naplózási sebességtől, a tranzakció méretétől, a replika terheltségétől és egyéb tényezőktől függ. A kis tranzakciók jellemző adatkésése több tíz ezredmásodpercben van, de nincs felső határa az adatkésésnek. Egy adott másodlagos replikán lévő adatok mindig tranzakciós konzisztensek, így a nagyobb tranzakciók propagálása hosszabb időt vesz igénybe. Egy adott időpontban az adatok késése és az adatbázis állapota eltérő lehet a különböző másodlagos replikák esetében. Azoknak a számítási feladatoknak, amelyeknek azonnal be kell olvasniuk a véglegesített adatokat, az elsődleges replikán kell futniuk.

Használható egy névvel ellátott replika kiesési célpontként?

Nem, az elnevezett replikák nem használhatók feladatátvételi célokra az elsődleges replikák esetében. Ha-replikákat adhat hozzá az elsődleges replikához erre a célra.

Hogyan oszthatok el írásvédett számítási feladatot a nevesített replikáim között?

Mivel minden elnevezett replika eltérő szolgáltatási szintű célkitűzéssel rendelkezhet, és így különböző felhasználási esetekhez használható, nincs beépített mód a csak olvasható forgalomnak az elsődlegesről történő irányítására vagy továbbítására egy nevesített replikák halmazára. Például nyolc elnevezett replikával rendelkezhet, és előfordulhat, hogy az OLTP-számítási feladatot csak az 1–4. nevű replikákra szeretné irányítani, míg a Power BI elemzési számítási feladatai az 5. és a 6. nevű replikát használják, az adatelemzési számítási feladat pedig a 7. és a 8. replikát. Attól függően, hogy milyen eszközt vagy programozási nyelvet használ, az ilyen számítási feladatok elosztására szolgáló stratégiák eltérőek lehetnek. Ha például olyan számítási feladat-útválasztási megoldást hoz létre, amely lehetővé teszi a REST-háttérrendszer vertikális felskálázását, tekintse át az OLTP vertikális felskálázási mintát.

Lehet egy elnevezett replika az elsődleges replika régiójától eltérő régióban?

Nem, mivel a nevesített replikák az elsődleges replika ugyanazon lapkiszolgálóit használják, ugyanabban a régióban kell lenniük. Ha azonban egy másik régióban létrehozott egy georeplikát az elsődleges replikához, létrehozhat elnevezett replikákat a georeplikához.

Befolyásolhatja egy elnevezett replika az elsődleges replika rendelkezésre állását vagy teljesítményét?

A névvel ellátott replika nem befolyásolhatja az elsődleges replika rendelkezésre állását. A nevesített replikák normál körülmények között valószínűleg nem befolyásolják az elsődleges teljesítményt, de ez akkor fordulhat elő, ha intenzív számítási feladatok futnak. A HA-replikához hasonlóan egy elnevezett replikátum is szinkronizálódik az elsődleges példánnyal a tranzakciónapló szolgáltatás révén. Ha egy elnevezett replika bármilyen okból nem tudja elég gyorsan felhasználni a tranzakciós naplót, megkéri az elsődleges replikát, hogy csökkentse a naplólétrehozási arányt, hogy felzárkózhasson. Bár ez a viselkedés nem befolyásolja az elsődleges rendelkezésre állását, hatással lehet az elsődleges írási műveletek teljesítményére. A helyzet elkerülése érdekében győződjön meg arról, hogy a megnevezett replikák elegendő erőforrással - főként CPU-val - rendelkeznek a tranzakciós napló késedelem nélküli feldolgozásához. Ha például az elsődleges számos adatváltozást dolgoz fel, javasoljuk, hogy legalább az elsődleges számítási mérettel megegyező nevű replikákkal rendelkezzen, hogy ne telíthesse át a processzort a replikákon, és az elsődlegest lelassítsa.

Mi történik az elnevezett replikákkal, ha az elsődleges replika nem érhető el, például tervezett karbantartás miatt?

A nevesített replikák a szokásos módon továbbra is elérhetők csak olvasásra.

Hogyan javíthatom a nevesített replikák rendelkezésre állását?

Alapértelmezés szerint az elnevezett replikák nem rendelkeznek saját HA-replikákkal. Egy elnevezett replika átvételéhez előbb egy új replikát kell létrehozni, ami általában körülbelül 1–2 percet vesz igénybe. Az elnevezett replikák azonban a HA-replikák által nyújtott magasabb rendelkezésre állás és rövidebb átállás előnyeit is élvezhetik. Nevezett replikához HA-replikákat adhat hozzá az Azure Portalon, vagy az ha-replicas paramétert használhatja az AZ CLI-ben, illetve HighAvailabilityReplicaCount paramétert a PowerShell-ben, vagy a highAvailabilityReplicaCount tulajdonságot a REST API-ban. A HA-replikák száma beállítható egy elnevezett replika létrehozásakor, és bármikor módosítható a nevesített replika létrehozása után. Az elnevezett replikákhoz tartozó HA-replikák díjszabása megegyezik az elsődleges replikákhoz tartozó HA-replikák díjszabásával.

Ha az Always Encrypted engedélyezve van a Hyperscale adatbázison, az elsődleges adatbázison végzett Oszlop főkulcs (CMK) forgatása frissíti a kulcsot a másodlagos replikákon is?

Igen. A oszlop főkulcsának a felhasználói adatbázisban van tárolva, és a lekérdezés SELECT * FROM sys.column_master_keysvégrehajtásával érvényesíthető. Az elnevezett replikák és a magas rendelkezésre állású másodlagos replikák az elsődleges rugalmas skálázású adatbázissal azonos lapkiszolgálókról/tárolási rétegből olvasnak be adatokat. A rendszer mindkét replikatípust szinkronizálja az elsődleges rugalmas skálázású adatbázissal a naplószolgáltatáson keresztül. A kulcsmódosítások tranzakciónak minősülnek, és automatikusan replikálódnak az összes másodlagos replikára.

Hogyan kérdezhetem le a rugalmas skálázású adatbázis másodlagos replikáival kapcsolatos információkat?

A DMF használatával sys.dm_hs_database_replicas csatlakozhat az elsődleges replikához, és meghatározhatja annak replikaazonosítóját és más másodlagos replikák részleteit. További információ: sys.dm_hs_database_replicas. Az alábbi példa egy sort ad vissza egy rugalmas skálázású adatbázis Contosodbminden replikájához.

SELECT replica_role_desc, replica_server_name, replica_id
FROM sys.dm_hs_database_replicas(DB_ID(N'Contosodb'));

A másodlagos replikához is csatlakozhat a replika azonosítójának és egyéb részleteinek meghatározásához. A sys.dm_database_replica_states alábbi minta lekérdezése az aktuális replikakörnyezet részleteit mutatja be:

  SELECT replica_id,
         DB_NAME() AS named_replica_database_name,
         synchronization_state_desc,
         log_send_queue_size / 1024.0 / 1024.0 AS log_send_queue_size_gb,
         last_sent_time,
         last_received_time,
         last_commit_time,
         redo_queue_size / 1024.0 / 1024.0 AS redo_queue_size_gb,
         redo_rate,
         secondary_lag_seconds
  FROM sys.dm_database_replica_states
  WHERE is_local = 1
        AND
        replica_id = DATABASEPROPERTYEX(DB_NAME(), 'ReplicaID');

Kapcsolódó tartalom

A rugalmas skálázási szolgáltatási szinttel kapcsolatos további információkért lásd rugalmas skálázású szolgáltatási szint.

A következőkre vonatkozik:Azure SQL Database

Ez a cikk választ ad azoknak a gyakori kérdéseknek, amelyek az Azure SQL Database Hyperscale szolgáltatási rétegén belüli adatbázis iránt érdeklődő ügyfeleket foglalkoztatják, és amelyet a továbbiakban csak Hyperscale-ként említünk. Ez a cikk a rugalmas skálázás által támogatott forgatókönyveket és a rugalmas skálázással kompatibilis funkciókat ismerteti.

• Ez a GYIK azon olvasók számára készült, akik rövid ismeretekkel rendelkeznek a Hyperscale szolgáltatási szintről, és szeretnék, ha a konkrét kérdéseik és aggályaik meg lennének válaszolva.
• Ez a gyakori kérdések nem útmutatók, és nem válaszolnak a rugalmas skálázású adatbázisok használatára vonatkozó kérdésekre. A rugalmas skálázásról Azure SQL Database rugalmas skálázásicímű cikkben olvashat.

A Hyperscale adatbázis olyan adatbázis az Azure SQL Database-ben, amelyet a Hyperscale skálázású tárolási technológia támogat. A rugalmas skálázású adatbázisok legfeljebb 128 TB-os adatot támogatnak, és magas átviteli sebességet és teljesítményt, valamint gyors skálázást biztosítanak a számítási feladatok követelményeinek megfelelően. A kapcsolat, a lekérdezésfeldolgozás, az adatbázismotor funkciói és így tovább, úgy működnek, mint az Azure SQL Database bármely más adatbázisában.

A Hyperscale szolgáltatási szint elérhető egyes adatbázisokhoz (mind kiépített, mind kiszolgáló nélküli) és elastic poolokhoz a vCore-alapú vásárlási modell használatával. A DTU-alapú vásárlási modellben nem érhető el.

A virtuális magalapú szolgáltatási szintek megkülönböztethetők az adatbázis rendelkezésre állása, tárolási típusa, teljesítménye és maximális tárterülete alapján, ahogyan azt az erőforráskorlátok összehasonlítása leírja.

A rugalmas skálázási szolgáltatási szint minden olyan ügyfél számára érhető el, aki nagyobb teljesítményt és rendelkezésre állást, gyors biztonsági mentést és visszaállítást, gyors tárolást és számítási méretezhetőséget keres. Ide tartoznak a kis és növekvő ügyfelek, a nagy, kritikus fontosságú adatbázisokat futtató ügyfelek, a felhőbe költöző ügyfelek, az alkalmazások és az Azure SQL Database-ben már más szolgáltatási szinteket használó ügyfelek.

A Hyperscale-val a következőket érheti el:

• Az adatbázis mérete 10 GB-ról 128 TB-ra nőhet, függetlenül a számítási mérettől.
• Virtuális mag erőforrásainak kiszámítása 2 virtuális magtól 192 virtuális magig.
• Gyors adatbázis-biztonsági mentések az adatbázis méretétől függetlenül (a biztonsági mentések a tárolási pillanatképeken alapulnak).
• Az adatbázis méretétől függetlenül gyors adatbázis-visszaállítások (a visszaállítások a tárolási pillanatképekből származnak).
• Nagyobb tranzakciónapló-átviteli sebesség az adatbázis méretétől és a virtuális magok számától függetlenül.
• Olvasási skálázás felfelé egy vagy több olvasásra szánt replikákkal, amelyeket írásvédett számítási feladatok áthelyezésére vagy meleg készenléti adatbázisokként használnak.
• A számítási kapacitás gyors felskálázása konstans idő alatt, hogy nagyobb teljesítményű legyen a nagy terhelés kezeléséhez, majd a kapacitás leskálázása konstans idő alatt. A skálázási műveletek egyjegyű perceket vesznek igénybe a kiépített számításhoz, a kiszolgáló nélküli számításhoz pedig kevesebb mint egy másodpercet, függetlenül az adatbázis méretétől.
• A kiszolgáló nélküli számítással használt adatokért való fizetés lehetősége, ahol a számítás számlázása a használat alapján történik.

A rugalmas skálázási szolgáltatási szint minden olyan régióban elérhető, ahol az Azure SQL Database elérhető.

Igen. A kiszolgálónkénti adatbázisok számával kapcsolatos további információkért és korlátozásokért tekintse meg kiszolgálóiönálló és készletezett adatbázisok SQL Database-erőforráskorlátait.

A rugalmas skálázási architektúra nagy teljesítményt és átviteli sebességet biztosít, miközben támogatja a nagy méretű adatbázisokat.

A rugalmas skálázás gyors méretezhetőséget biztosít a számítási feladatok igényeinek megfelelően.

• fel- és leskálázás

  A rugalmas skálázással az elsődleges számítási méretet vertikálisan felskálázhatja az erőforrások, például a processzor és a memória tekintetében, majd folyamatosan leskálázhatja a méretet. Mivel a tárolás távoli, a felméretezés és lekicsinyítés nem adatméret-művelet.

  A kiszolgáló nélküli számítás támogatása automatikus felskálázást, leskálázást és számítási költségek számlázását biztosít a használat alapján.

• skálázás be/kimenet

  A Hyperscale szolgáltatással háromféle másodlagos replika használható az olvasási kapacitás növeléséhez, a magas rendelkezésre állás biztosításához és a földrajzi replikációs követelmények kielégítéséhez. Ez a következőket foglalja magában:

  • Legfeljebb négy magas rendelkezésre állású replika ugyanazzal a számítási méretel, mint az elsődleges. Ezek gyors készenléti replikaként szolgálnak az elsődleges feladatátvételhez. Használhatja őket az olvasási műveletek elsődleges rendszerről való tehermentesítésére is.
  • Legfeljebb 30 elnevezett replika, amelyek az elsődlegesnél azonos vagy eltérő számítóméterrel rendelkeznek, hogy különböző olvasási felskálázási forgatókönyveket támogassanak.
  • Egy georeplika egy másik Azure-régióban a regionális kimaradások elleni védelemhez és a földrajzi olvasási felskálázás engedélyezéséhez.

Igen, megteheted.

Nem, az alkalmazásprogramozási modell ugyanaz marad, mint bármely más MSSQL-adatbázis esetében. A kapcsolati karakterláncot a szokásos módon használja, és szokásos módon lép kölcsönhatásba a Hyperscale adatbázissal. Miután az alkalmazás a rugalmas skálázású adatbázist használja, az alkalmazás kihasználhatja az olyan funkciók előnyeit, mint például másodlagos replikák.

Az elsődleges replikán az alapértelmezett tranzakcióelkülönítési szint READ COMMITTED, az READ_COMMITTED_SNAPSHOT adatbázis-beállítás (RCSI) engedélyezése mellett. A másodlagos replikák elkülönítési szintje SNAPSHOT. Ez ugyanaz, mint bármely más Azure SQL-adatbázisban.

Az új, egyszerűsített díjszabás 2023. december 15. óta érvényes, így az újonnan létrehozott rugalmas skálázású adatbázisok, a kiszolgáló nélküli rugalmas skálázású adatbázisok és az összes rugalmas skálázású készlet számítási ára csökkent. Az új, egyszerűsített díjszabással nem szükséges az Azure Hybrid Benefit (AHB) alkalmazása az ezzel egyenértékű megtakarítás eléréséhez. Az Azure Hybrid Benefit (AHB) csak régebbi (2023. december 15. előtt létrehozott) rugalmas skálázású önálló adatbázisokra alkalmazható kiépített számítással. A régebbi adatbázisok esetében az AHB csak 2026 decemberéig alkalmazható, amely után az adatbázisok számlázása is az új, egyszerűsített díjszabás szerint történik.

További információ: Rugalmas skálázási díjszabás blog és Azure SQL Database Rugalmas skálázás – alacsonyabb, egyszerűsített díjszabási.

A rugalmas skálázás minden számítási feladattípushoz jól működik, beleértve az OLTP, a hibrid (HTAP) és az elemzési (adatbővítő) számítási feladatokat.

Ha jelenleg interaktív elemzési lekérdezéseket futtat az SQL Server adattárházként való használatával, a rugalmas skálázás nagyszerű lehetőség, mivel kisebb és közepes méretű adattárházakat (például néhány TB-ot akár 128 TB-ot) is üzemeltethet alacsonyabb költséggel, és minimális T-SQL-kódmódosításokkal migrálhatja az SQL Server-adattárház számítási feladatait rugalmas skálázásba.

Ha nagy léptékű adatelemzést futtat összetett lekérdezésekkel és 100 MiB/s-nél magasabb tartós betöltési arányokkal, vagy párhuzamos adattárház (PDW), Teradata vagy más nagymértékben párhuzamos feldolgozási (MPP) adattárházak, például az Azure Synapse Analytics használatával, akkor a Microsoft Fabric lehet a legjobb választás.

A betöltési vagy naplógenerálási arány adatbázisonként 150 MiB/s az Azure SQL Database hiperskálázású prémium sorozatú és prémium memóriaoptimalizált hardverén. Standard sorozatú hardverek esetén a maximális naplósebesség adatbázisonként 100 MiB/s. Rugalmas készletek esetén a maximális naplózási sebesség készletenként 150 MiB/s a prémium sorozatú és prémium sorozatú memóriaoptimalizált hardverek esetében, valamint készletenként 125 MiB/s a többi hardver esetében.

Jelenleg nem. A számítási kapacitást és a replikák számát azonban csökkentheti, hogy csökkentse a költségeket a nem csúcsidőszakban, vagy a serverless használatával automatikusan skálázhatja a számítási kapacitást a használat függvényében.

Olvasási számítási feladatokhoz létrehozhat egy nevű replikát, nagyobb számítási mérettel (több maggal és memóriával) rendelkezik, mint az elsődleges. A rendelkezésre álló számítási méretekről további információt Rugalmas skálázású tárterület és számítási méretekcímű témakörben talál.

Olvasási számítási feladatok esetében ez elnevezett replikákhasználatával érhető el.

A másodlagos HA-replikák számát 0 és 4 között skálázhatja az Azure Portal vagy REST APIhasználatával. Emellett akár 30 elnevezett replikát is létrehozhat sok olvasási skálázási esethez. Minden elnevezett replika legfeljebb 4 másodlagos HA replikával rendelkezhet.

Rugalmas skálázású adatbázisokban az adatrugalmasság a tárolási szinten biztosított. A rugalmasság biztosításához csak egy replikára (az elsődleges) van szüksége. Ha a számítási replika meghibásodik vagy karbantartás alatt áll, a rendszer automatikusan létrehoz egy új replikát adatvesztés nélkül.

Ha azonban csak az elsődleges replika található, egy-két percig is eltarthat egy új replika létrehozása, szemben másodpercekkel abban az esetben, ha egy másodlagos HA-replika érhető el. Az új replika kezdetben hideg gyorsítótárakat fog tartalmazni, ami nagyobb tárolási késést és kevesebb lekérdezési teljesítményt eredményezhet közvetlenül a feladatátvétel után.

Az olyan kritikus fontosságú alkalmazások esetében, amelyek minimális feladatátvételi hatással járó magas rendelkezésre állást igényelnek, legalább egy másodlagos HA-replikát ki kell építenie, hogy a gyakori készenléti replika rendelkezésre álljon feladatátvételi célként.

Egy rugalmas skálázású adatbázis maximális mérete jelenleg 128 TB, a számítási mérettől függetlenül. A Hyperscale rugalmas készletben egy adatbázis maximális mérete jelenleg 100 TB.

Rugalmas skálázás esetén a tranzakciónapló gyakorlatilag végtelen, azzal a korlátozással, hogy a napló aktív része nem haladhatja meg az 1 TB-ot. A napló aktív része a hosszú ideig futó tranzakciók miatt növekedhet, vagy Adatrögzítés módosítása feldolgozás nem tartja lépést az adatváltozás sebességével. Kerülje a szükségtelenül hosszú és nagy tranzakciókat, hogy a korlát alatt maradjon. A korlátozáson kívül nem kell aggódnia amiatt, hogy elfogy a naplóterület egy olyan rendszeren, amely magas naplózási átviteli sebességgel rendelkezik. A naplók előállítási aránya azonban csökkenthető a folyamatos nagy intenzitású írási feladatok esetében. A naplógenerálási arány 150 MiB/s a prémium sorozatú és prémium sorozatú memóriaoptimalizált hardverekhez, valamint 100 MiB/s más hardverekhez.

A tempdb adatbázis a helyi SSD-tárolóban található, és a kiépített számítási méret (a magok száma) arányában van méretezve. A(z) tempdb mérete nem konfigurálható, és automatikusan van kezelve Önnek. Az adatbázis maximális tempdb méretének meghatározásához tekintse meg rugalmas skálázású tároló- és számítási méreteket.

Az adatbázis mérete automatikusan nő a további adatok beszúrása/betöltésekor.

10 GB. A rugalmas skálázású adatbázis 10 GB kezdőmérettel jön létre, és igény szerint növekszik.

Minden adatfájl 10 GB-kal nő. Egyszerre több adatfájl is növekedhet.

Rugalmas skálázás esetén az adatfájlok tárolása az Azure Standard Storage-ban történik. Az adatok teljes mértékben gyorsítótárazva vannak a helyi SSD-tárolóban, a számítási replikáktól távoli lapkiszolgálókon. Emellett a számítási replikák adatgyorsítótárakat is tárolnak a helyi SSD-n és a memóriában, hogy csökkenjen az adatok távoli lapkiszolgálókról való lekérésének gyakorisága.

Nem. A rendszer automatikusan hozzáadja az adatfájlokat a PRIMARY fájlcsoporthoz. A további fájlcsoportok létrehozásának gyakori okai nem alkalmazhatók a rugalmas skálázású tárolóarchitektúrában vagy az Azure SQL Database-ben.

Nem.

Igen, adatbázis- és fájlzsugorítási műveletek támogatottak az Azure SQL Database rugalmas skálázásában.

Igen, csakúgy, mint bármely más Azure SQL DB-adatbázisban. Ide tartoznak a sor-, oldal- és oszlop.

Igen. Az adott táblához társított adatlapok több adatfájlba is tartozhatnak, amelyek mind ugyanahhoz a fájlcsoporthoz tartoznak. Az MSSQL adatbázismotor arányos kitöltési stratégiát az adatok adatfájlokon keresztüli elosztásához.

Igen. A koncepcióigazolások (POC-k) esetében javasoljuk, hogy készítsen másolatot az adatbázisról, és migrálja a másolatot Hyperscale-re.

A meglévő adatbázisok rugalmas skálázásba való áthelyezéséhez szükséges idő az adatok másolásának ideje, valamint a forrásadatbázisban végrehajtott módosítások visszajátszásának ideje az adatok másolása során. Az adatmásolási idő arányos az adatméretével. A módosítások visszajátszásának ideje rövidebb, ha az áthelyezés alacsony írási tevékenység időszakában történik.

Meglévő Azure SQL Database-adatbázist rugalmas skálázásúvá alakíthat az Azure Portalon, az Azure CLI-ben, a PowerShellben és a Transact-SQL-ben. További információ: Az adatbázis átalakítása hiperskálázhatóvá.

Fordított migrálás az Általános célú szolgáltatási szintre lehetővé teszi, hogy azok az ügyfelek, akik nemrég migráltak egy meglévő adatbázist az Azure SQL Database-ben a Hyperscale szolgáltatási szintre, visszaléphessenek, ha a Hyperscale nem felel meg az igényeiknek. Bár a fordított migrálást egy szolgáltatási szint módosítása kezdeményezi, ez lényegében egy adatméret-művelet a különböző architektúrák között. A rugalmas skálázásra való migráláshoz hasonlóan a fordított migrálás is gyorsabb, ha alacsony írási tevékenység alatt történik. További információért lásd: Hyperscale-ből való visszamigrálás.

Ha korábban már migrált egy meglévő Azure SQL Database-adatbázist a rugalmas skálázási szolgáltatási szintre, az eredeti rugalmas skálázásra való migrálást követő 45 napon belül visszatelepítheti azt 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 térjen vissza az Általános célú szolgáltatási szintre, majd módosítsa a szolgáltatási szintet. A fordított migrálás adatméretű művelet.

A rugalmas skálázású szolgáltatási szinten létrehozott adatbázisok nem helyezhetők át más szolgáltatási szintekre.

Ismerje meg, hogyan fordíthatja vissza a migrálást a Hyperscale-ből, beleértve a fordított migrálás korlátozásait és a biztonsági mentési szabályzatokat.

Igen. Az Azure SQL Database egyes funkciói nem támogatottak a rugalmas skálázásban. Ha ezen funkciók némelyike engedélyezve van az adatbázishoz, a rugalmas skálázásra való migrálás blokkolható, vagy ezek a funkciók az áttelepítés után leállnak. További információ: Ismert korlátozások.

Igen. Számos meglévő migrálási technológiát használhat a rugalmas skálázásba való migráláshoz, beleértve a tranzakciós replikációt és bármely más adatátviteli technológiát (tömeges másolás, Azure Data Factory, Azure Databricks, SSIS). Lásd még a Azure Database Migration Service, amely számos migrálási forgatókönyvet támogat.

A Hyperscale-re történő migrálás állásideje megegyezik az adatbázisok más Azure SQL Database-szolgáltatási szintekre történő migrálásának állásidejével. A tranzakciós replikáció használatával minimalizálhatja az állásidőt a néhány TB méretű adatbázisok migrálása során. Nagyon nagy adatbázisok (10+ TB) esetén megfontolhatja a migrálási folyamat implementálását az ADF, a Spark vagy más tömeges adatáthelyezési technológiák használatával.

A rugalmas skálázás legfeljebb 150 MiB/s új/módosított adatot képes felhasználni, de az Azure SQL Database adatbázisaiba való áthelyezéshez szükséges időt a rendelkezésre álló hálózati átviteli sebesség, a forrásolvasási sebesség, a terhelés típusa (tömeges és sorról sorra) és a céladatbázis szolgáltatásiszint-célkitűzése is befolyásolja.

Az ügyfélalkalmazás adatokat olvashat be az Azure Storage-ból, és betöltheti az adatokat egy rugalmas skálázású adatbázisba (ugyanúgy, mint bármely más Azure SQL Database-adatbázis esetében). A Polybase jelenleg nem támogatott az Azure SQL Database-ben. A gyors terhelés alternatívaként használja az Azure Data Factoryt.

Az Adatok tömeges beolvasása az Azure Blob Store-ból a BULK INSERT vagy az OPENROWSET használatával is lehetséges: Példák az Adatok tömeges elérésére az Azure Blob Storage-ban.

Az egyszerű vagy csoportos naplózott helyreállítási modellek nem támogatottak Hyperscale-ban. A magas rendelkezésre állás és az időponthoz kötött helyreállítás biztosításához teljes helyreállítási modell szükséges. A rugalmas skálázású naplóarchitektúra azonban jobb adatbetöltési sebességet biztosít a többi Azure SQL Database-szolgáltatási szinthez képest.

Nem. A Hyperscale szimmetrikus többfeldolgozós (SMP) architektúra, nem pedig nagymértékben párhuzamos feldolgozás (MPP) vagy többmester-architektúra. Több replikát is létrehozhat a csak olvasható feladatok horizontális felskálázásához.

Igen. Azure Database Migration Service számos migrálási forgatókönyvet támogat.

A rugalmas skálázású számlázás az átalakítás után csak az átállás befejezése után kezdődik.

Igen. Az átalakítás indításakor megadhatja az átállás jellegét. A folyamat automatikus lehet, amint készen áll, vagy manuálisan is elindítható, amikor készen áll. További információ: Adatbázis konvertálása rugalmas skálázásra. Az átállást manuálisan is kezdeményezheti az Azure Portalon, a PowerShellen, az Azure CLI-en vagy a T-SQL-en keresztül. Az Hyperscale-re való végleges átállás során csak rövid, általában egy percnél rövidebb állásidőt fog tapasztalni.

Lásd Azure SQL DatabaseSLA-ját. Javasoljuk, hogy adjon hozzá másodlagos HA-replikákat a kritikus munkaterhelésekhez. Ez gyorsabb feladatátvételt biztosít, és közvetlenül a feladatátvétel után csökkenti a lehetséges teljesítményhatást.

Igen.

Igen, a Hyperscale támogatja a zónaredundáns konfiguráció-t. A Hyperscale számára a zónaredundáns konfiguráció engedélyezéséhez legalább egy másodlagos HA-replika, valamint zónaredundáns vagy geozónaredundáns tároló szükséges.

Igen. További információ: Rugalmas rugalmas készletek és Blog: A rugalmas rugalmas készletek mostantól általánosan elérhetők.

A Hyperscale adatbázisokhoz nincsenek hagyományos teljes, különbségi és tranzakciónapló-biztonsági mentések. Ehelyett az adatfájlok rendszeres tárolási pillanatképei vannak, és mindegyik fájlhoz külön pillanatkép-ütemezés tartozik. A létrehozott tranzakciónapló a konfigurált megőrzési időszak alatt változatlan formában marad. A visszaállításkor a rendszer a megfelelő tranzakciónapló-rekordokat alkalmazza a visszaállított tárolási pillanatképekre. A pillanatképek gyakoriságától függetlenül ez egy tranzakciós konzisztens adatbázist eredményez a megőrzési időszakon belül megadott időponttól kezdve, adatvesztés nélkül. A Hyperscale adatbázis biztonsági mentése folyamatos.

Igen.

Az időponthoz kötött visszaállítás RPO-jának időtartama 0 perc. A legtöbb időponthoz kötött visszaállítási művelet az adatbázis méretétől függetlenül 60 percen belül befejeződik. A visszaállítási idő hosszabb lehet a nagyobb adatbázisok esetében, és ha az adatbázis jelentős írási tevékenységet tapasztalt a visszaállítási időpontig. A tárterület-redundancia legutóbbi módosítása után a visszaállítási hosszabb visszaállítási időt eredményezhet, mivel ebben az esetben a visszaállítás adatméretű művelet lehet, és a visszaállítási idő arányos lehet az adatbázis méretével.

Nem. A biztonsági mentéseket a tárolási alrendszer felügyeli, és tárolási pillanatképeket használ. Ezek nem befolyásolják a felhasználói számítási feladatokat.

Igen. Geo-helyreállítás teljes mértékben támogatott, ha georedundáns vagy geo-zónaredundáns tárolást használnak. Az új adatbázisok esetében a georedundáns tárolás az alapértelmezett. Az időpillanat alapú visszaállításhoz képest a geovisszaállítás adatméret-műveletet igényel. Az adatfájlok párhuzamos másolása így a művelet időtartama elsősorban az adatbázis legnagyobb fájljának méretétől függ, nem pedig az adatbázis teljes méretétől. A georedundáns visszaállítási idő jelentősen rövidebb, ha az adatbázis a forrásadatbázis régiójával párosított Azure-régióban van visszaállítva . További információkért lásd: Az Azure SQL Databasegeo-visszaállítása.

Igen. georeplikációs és feladatátvételi csoportok beállíthatók rugalmas skálázású adatbázisokhoz.

Nem. A rugalmas skálázású adatbázisok tárolási formátuma eltér az SQL Server bármely kiadott verziójától, és nem szabályozza a biztonsági mentéseket, és nem rendelkezik hozzáféréssel hozzájuk. Ha adatokat szeretne kinyerni egy rugalmas skálázású adatbázisból, bármilyen adatáthelyezési technológiával kinyerheti az adatokat, például az Azure Data Factoryt, az Azure Databrickset, az SSIS-t stb.

Igen. 2022. május 4-én az összes új adatbázis biztonsági mentését a felhasznált biztonsági mentési tárterület és a kiválasztott tárterület-redundancia alapján számítjuk fel az Azure SQL Database díjszabási oldalán . A 2022. május 4. előtt létrehozott rugalmas skálázású adatbázisok esetében a biztonsági mentések csak akkor kerülnek felszámításra, ha a biztonsági másolatok megőrzési ideje hét napnál hosszabb. További információ: rugalmas skálázású biztonsági mentések és tárolóredundancia.

A biztonsági másolatok tárolási méretének méréséről további információt Automatikus biztonsági mentésekcímű témakörben talál.

A biztonsági mentési tárterület díjának meghatározásához a biztonsági mentési tárterület méretét rendszeres időközönként számítjuk ki, és megszorozzuk a biztonsági mentés tárolási sebességével és az utolsó számítás óta eltelt órák számával. A biztonsági mentési számla időszakonkénti becsléséhez szorozza meg az időszak minden órájára vonatkozó számlázható biztonsági mentési tárterület méretét a biztonsági mentés tárolási sebességével, és adja hozzá az összes óránkénti összeget. A releváns Azure Monitor-metrikák programozott módon történő lekérdezéséhez használja az Azure Monitor REST API. A kiszolgáló nélküli számítási szint biztonsági mentésének számlázása megegyezik a kiépített számítási szint számlázásával.

A biztonsági mentési költségek magasabbak az olyan számítási feladatok esetében, amelyek nagy mennyiségű adatot adnak hozzá, módosítanak vagy törölnek az adatbázisban. Ezzel szemben a többnyire írásvédett számítási feladatok alacsonyabb biztonsági mentési költségekkel járhatnak.

A biztonsági mentés tárolási költségeinek minimalizálásáról további információt Automatikus biztonsági mentésekcímű témakörben talál.

Jelenleg a nem rugalmas skálázású szolgáltatási szintek (Alapszintű/Standard/Prémium/Általános célú/Üzleti szempontból kritikus) biztonsági másolatok nem állíthatók vissza georeduktívan rugalmas skálázású szolgáltatási szintre, és fordítva. Ha nem rugalmas skálázású adatbázist szeretne rugalmas skálázású adatbázissá alakítani, módosítsa a szolgáltatási szintet a visszaállítás után.

A tranzakciónapló átviteli korlátja 100 MiB/s bármilyen Hyperscale számítási mérethez. A sebesség elérésének lehetősége több tényezőtől függ, többek között a számítási feladatok típusától, az ügyfélkonfigurációtól és a teljesítménytől, és az elsődleges számítási replikán elegendő számítási kapacitással rendelkezik a naplórekordok ilyen sebességgel történő létrehozásához. A betöltési vagy naplógenerálási arány adatbázisonként 150 MiB/s az Azure SQL Database hiperskálázású prémium sorozatú és prémium memóriaoptimalizált hardverén. Standard sorozatú hardverek esetén a maximális naplósebesség adatbázisonként 100 MiB/s. Rugalmas készletek esetén a maximális naplózási sebesség készletenként 150 MiB/s a prémium sorozatú és prémium sorozatú memóriaoptimalizált hardverek esetében, valamint készletenként 125 MiB/s a többi hardver esetében.

Az IOPS és az IO késése a számítási feladatok mintáitól függően változik. Ha a hozzáférő adatok gyorsítótárazva lesznek a számítási replika helyi SSD-tárolójában, hasonló IO-teljesítményt fog látni, mint az üzletileg kritikus vagy prémium szolgáltatási szinteken.

Nem. A számítás leválasztva van a tárolási rétegről. Ez kiküszöböli a biztonsági mentés teljesítményre gyakorolt hatását.

Mivel a tároló meg van osztva, és nem történik közvetlen fizikai replikáció az elsődleges és a másodlagos számítási replikák között, az elsődleges replika átviteli sebességét nem befolyásolja közvetlenül másodlagos replikák hozzáadása. A folyamatos és agresszív írási feladatok naplósebessége azonban korlátozott lehet az elsődlegesnél, hogy lehetővé tegye a napló alkalmazását a másodlagos replikákon és a lapkiszolgálókon, hogy azok felzárkózzanak. Ez elkerüli a másodlagos replikák gyenge olvasási teljesítményét és a hosszú helyreállítást a HA másodlagos replikára történő feladatátvétel után.

Igen. A többi Azure SQL-adatbázishoz hasonlóan azonban előfordulhat, hogy a kapcsolatok nagyon ritkán átmeneti hibákkal végződnek, amelyek megszakíthatják a hosszú ideig futó lekérdezéseket és visszaállíthatják a tranzakciókat. Az átmeneti hibák egyik oka, hogy a rendszer gyorsan áthelyezi az adatbázist egy másik számítási csomópontra, hogy biztosítsa a számítási és tárolási erőforrások folyamatos rendelkezésre állását, vagy tervezett karbantartást végezzen. Az újrakonfigurálási események többsége kevesebb mint 10 másodperc alatt fejeződik be. Az adatbázishoz csatlakozó alkalmazásokat úgy kell létrehozni, hogy az újrapróbálkozási logika implementálásával elvárják és tolerálják ezeket a ritkán előforduló átmeneti hibákat. Emellett érdemes lehet konfigurálni egy karbantartási időszak, amely megfelel a számítási feladatok ütemezésének, hogy elkerülje a tervezett karbantartás miatti átmeneti hibákat.

A legtöbb teljesítményproblémára, különösen a tárolási teljesítményben gyökerező problémákra az MSSQL gyakori diagnosztikai és hibaelhárítási lépései érvényesek. A Hyperscale-specifikus tárolási diagnosztikával kapcsolatos információkért lásd a SQL Hyperscale teljesítmény hibaelhárítási diagnosztika című témakört.

A kiszolgáló nélküli adatbázisok által felskálázható maximális memóriamennyiség 3 GB/virtuális mag a konfigurált virtuális magok maximális számának 3 GB/vCore-szorosa, szemben a kiosztott számításban lévő virtuális magok számával több mint 5 GB/virtuális magmal. Részletekért tekintse át kiszolgáló nélküli rugalmas skálázási erőforráskorlátokat.

A folyamatos feltöltés segít fenntartani az RBPEX (rugalmas pufferkészletbővítmény) magasabb kihasználtságát, ami jobb teljesítményt eredményez. Biztosítja, hogy a másodlagos adatbázis mindig készen álljon a késedelem nélküli átvételre, ezáltal javítva a feladatátvételi időket és a rendszer általános megbízhatóságát.

A folyamatos inicializálás a kiosztott Hyperscale számítási szint prémium sorozatú hardverén és memóriaoptimalizált prémium sorozatú hardverén érhető el. A folyamatos alapozás jelenleg nem érhető el a kiszolgáló nélküli Hyper-skálázott számítási szint esetében.

Az elnevezett replikák nem élvezik a folyamatos előkészítés előnyeit.

A kiépített számítási szint fel- vagy leskálázása általában 2 percet vesz igénybe, az adatmérettől függetlenül. A kiszolgáló nélküli számítási rétegben, ahol a számítási feladat igényeinek megfelelően automatikusan skálázódik a számítás, a skálázási idő általában alszekundum, de esetenként akár a kiépített számítás skálázása is eltarthat.

Nem. Az adatbázis online állapotban marad a vertikális felskálázási vagy vertikális leskálázási műveletek során.

A kiosztott számítás fel- vagy leskálázása azt eredményezi, hogy a kapcsolatok megszakadnak, amikor feladatátvétel történik a skálázási művelet végén. A kiszolgáló nélküli számításban az automatikus skálázás általában nem eredményezi a kapcsolat megszakadását, de időnként előfordulhat. A másodlagos replikák hozzáadása vagy eltávolítása nem eredményezi a kapcsolat megszakadát az elsődlegesen.

A kiépített számításban a skálázást a végfelhasználó végzi. A kiszolgáló nélküli számítás automatikus skálázását a szolgáltatás végzi.

Igen. A tempdb adatbázis és számítási SSD-gyorsítótár számítási csomópontok mérete automatikusan felskálázódik a magok számának növekedésével. További információ: Rugalmas skálázású tároló és számítási méretek.

Nem. Csak az elsődleges számítási replika fogad olvasási/írási kéréseket. A másodlagos számítógépes másolatok csak olvasási kérelmeket fogadnak el.

A Hyperscale támogatja a magas rendelkezésre állású (HA) replikákat, a névvel ellátott replikákat és a geo-replikákat. Részletekért lásd rugalmas skálázású másodlagos replikákat.

0 és 4 között. Ha módosítani szeretné a replikák számát, ezt Azure Portal vagy REST APIhasználatával teheti meg.

Ezekhez a további írásvédett számítási replikákhoz úgy csatlakozhat, hogy a kapcsolati sztring ApplicationIntent tulajdonságát ReadOnlyértékre állítja. A ReadOnly megjelölt kapcsolatok automatikusan a másodlagos HA-replikák egyikére lesznek irányítva, ha vannak ilyenek. Részletekért lásd: Írásvédett replikák használata az írási műveletektől elkülönített lekérdezési terhelésekhez.

A következő T-SQL-lekérdezést hajthatja végre: SELECT DATABASEPROPERTYEX ('<database_name>', 'Updateability'). Az eredmény READ_ONLY, ha írásvédett másodlagos replikához csatlakozik, és READ_WRITE, ha az elsődleges replikához csatlakozik. Az adatbázis-környezetet az adatbázis nevére kell állítani, nem pedig a master adatbázisra.

Nem. Csak akkor csatlakozhat másodlagos replikákhoz, ha megadja a ApplicationIntent=ReadOnly. Azonban dedikált végpontokat is használhat elnevezett replikákhoz.

Nem. A csak olvasásra szánt új kapcsolatot bármelyik HA másodlagos replikára irányít át a rendszer.

Nem az előírt számítási rétegen. A másodlagos HA-replikák magas rendelkezésre állású feladatátvételi célként szolgálnak, ezért a feladatátvétel utáni várható teljesítmény biztosításához az elsődleges konfigurációval megegyező konfigurációval kell rendelkezniük. Kiszolgáló nélküli környezetben a számítási feladat automatikusan skálázódik az egyes HA-replikákhoz az egyéni számítási feladatok igényei alapján. Minden HA másodlagos továbbra is automatikusan skálázódhat a konfigurált maximális magokra, hogy elláthassa feladatátvétel utáni szerepkörét. elnevezett replikák lehetővé teszik az egyes elnevezett replikák egymástól függetlenül történő skálázását.

Nem. A tempdb adatbázis a kiosztott számítási méret alapján van konfigurálva; a másodlagos HA-replikák mérete megegyezik az elsődleges számítás méretével, beleértve a tempdb. elnevezett replikákontempdb a replika számítási méretének megfelelően méretezhető, így kisebb vagy nagyobb lehet, mint az elsődleges tempdb.

Nem. A rugalmas skálázású adatbázis számítási replikái osztoznak a tárolóban, ami azt jelenti, hogy minden számítási replika ugyanazokat a táblákat, indexeket és más adatbázis-objektumokat látja. Ha további indexeket szeretne optimalizálni a másodlagos olvasásokhoz, azokat hozzá kell adnia az elsődlegeshez. A másodlagos replikákon továbbra is létrehozhat ideiglenes táblákat (#vagy ##előtaggal ellátott táblaneveket), hogy ideiglenes adatokat tároljon a tempdb adatbázisban. Az ideiglenes táblák olvasási és írási lehetőséggel rendelkeznek.

Az adatkésés attól az időponttól kezdve, amikor egy tranzakció el van kötelezve az elsődleges rendszeren, és olvasható a másodlagos rendszeren, az aktuális naplózási sebességtől, a tranzakció méretétől, a replika terheltségétől és egyéb tényezőktől függ. A kis tranzakciók jellemző adatkésése több tíz ezredmásodpercben van, de nincs felső határa az adatkésésnek. Egy adott másodlagos replikán lévő adatok mindig tranzakciós konzisztensek, így a nagyobb tranzakciók propagálása hosszabb időt vesz igénybe. Egy adott időpontban az adatok késése és az adatbázis állapota eltérő lehet a különböző másodlagos replikák esetében. Azoknak a számítási feladatoknak, amelyeknek azonnal be kell olvasniuk a véglegesített adatokat, az elsődleges replikán kell futniuk.

Nem, az elnevezett replikák nem használhatók feladatátvételi célokra az elsődleges replikák esetében. Ha-replikákat adhat hozzá az elsődleges replikához erre a célra.

Mivel minden elnevezett replika eltérő szolgáltatási szintű célkitűzéssel rendelkezhet, és így különböző felhasználási esetekhez használható, nincs beépített mód a csak olvasható forgalomnak az elsődlegesről történő irányítására vagy továbbítására egy nevesített replikák halmazára. Például nyolc elnevezett replikával rendelkezhet, és előfordulhat, hogy az OLTP-számítási feladatot csak az 1–4. nevű replikákra szeretné irányítani, míg a Power BI elemzési számítási feladatai az 5. és a 6. nevű replikát használják, az adatelemzési számítási feladat pedig a 7. és a 8. replikát. Attól függően, hogy milyen eszközt vagy programozási nyelvet használ, az ilyen számítási feladatok elosztására szolgáló stratégiák eltérőek lehetnek. Ha például olyan számítási feladat-útválasztási megoldást hoz létre, amely lehetővé teszi a REST-háttérrendszer vertikális felskálázását, tekintse át az OLTP vertikális felskálázási mintát.

Nem, mivel a nevesített replikák az elsődleges replika ugyanazon lapkiszolgálóit használják, ugyanabban a régióban kell lenniük. Ha azonban egy másik régióban létrehozott egy georeplikát az elsődleges replikához, létrehozhat elnevezett replikákat a georeplikához.

A névvel ellátott replika nem befolyásolhatja az elsődleges replika rendelkezésre állását. A nevesített replikák normál körülmények között valószínűleg nem befolyásolják az elsődleges teljesítményt, de ez akkor fordulhat elő, ha intenzív számítási feladatok futnak. A HA-replikához hasonlóan egy elnevezett replikátum is szinkronizálódik az elsődleges példánnyal a tranzakciónapló szolgáltatás révén. Ha egy elnevezett replika bármilyen okból nem tudja elég gyorsan felhasználni a tranzakciós naplót, megkéri az elsődleges replikát, hogy csökkentse a naplólétrehozási arányt, hogy felzárkózhasson. Bár ez a viselkedés nem befolyásolja az elsődleges rendelkezésre állását, hatással lehet az elsődleges írási műveletek teljesítményére. A helyzet elkerülése érdekében győződjön meg arról, hogy a megnevezett replikák elegendő erőforrással - főként CPU-val - rendelkeznek a tranzakciós napló késedelem nélküli feldolgozásához. Ha például az elsődleges számos adatváltozást dolgoz fel, javasoljuk, hogy legalább az elsődleges számítási mérettel megegyező nevű replikákkal rendelkezzen, hogy ne telíthesse át a processzort a replikákon, és az elsődlegest lelassítsa.

A nevesített replikák a szokásos módon továbbra is elérhetők csak olvasásra.

Alapértelmezés szerint az elnevezett replikák nem rendelkeznek saját HA-replikákkal. Egy elnevezett replika átvételéhez előbb egy új replikát kell létrehozni, ami általában körülbelül 1–2 percet vesz igénybe. Az elnevezett replikák azonban a HA-replikák által nyújtott magasabb rendelkezésre állás és rövidebb átállás előnyeit is élvezhetik. Nevezett replikához HA-replikákat adhat hozzá az Azure Portalon, vagy az ha-replicas paramétert használhatja az AZ CLI-ben, illetve HighAvailabilityReplicaCount paramétert a PowerShell-ben, vagy a highAvailabilityReplicaCount tulajdonságot a REST API-ban. A HA-replikák száma beállítható egy elnevezett replika létrehozásakor, és bármikor módosítható a nevesített replika létrehozása után. Az elnevezett replikákhoz tartozó HA-replikák díjszabása megegyezik az elsődleges replikákhoz tartozó HA-replikák díjszabásával.

Igen. A oszlop főkulcsának a felhasználói adatbázisban van tárolva, és a lekérdezés SELECT * FROM sys.column_master_keysvégrehajtásával érvényesíthető. Az elnevezett replikák és a magas rendelkezésre állású másodlagos replikák az elsődleges rugalmas skálázású adatbázissal azonos lapkiszolgálókról/tárolási rétegből olvasnak be adatokat. A rendszer mindkét replikatípust szinkronizálja az elsődleges rugalmas skálázású adatbázissal a naplószolgáltatáson keresztül. A kulcsmódosítások tranzakciónak minősülnek, és automatikusan replikálódnak az összes másodlagos replikára.

A DMF használatával sys.dm_hs_database_replicas csatlakozhat az elsődleges replikához, és meghatározhatja annak replikaazonosítóját és más másodlagos replikák részleteit. További információ: sys.dm_hs_database_replicas. Az alábbi példa egy sort ad vissza egy rugalmas skálázású adatbázis Contosodbminden replikájához.

SELECT replica_role_desc, replica_server_name, replica_id
FROM sys.dm_hs_database_replicas(DB_ID(N'Contosodb'));

A másodlagos replikához is csatlakozhat a replika azonosítójának és egyéb részleteinek meghatározásához. A sys.dm_database_replica_states alábbi minta lekérdezése az aktuális replikakörnyezet részleteit mutatja be:

  SELECT replica_id,
         DB_NAME() AS named_replica_database_name,
         synchronization_state_desc,
         log_send_queue_size / 1024.0 / 1024.0 AS log_send_queue_size_gb,
         last_sent_time,
         last_received_time,
         last_commit_time,
         redo_queue_size / 1024.0 / 1024.0 AS redo_queue_size_gb,
         redo_rate,
         secondary_lag_seconds
  FROM sys.dm_database_replica_states
  WHERE is_local = 1
        AND
        replica_id = DATABASEPROPERTYEX(DB_NAME(), 'ReplicaID');

Kapcsolódó tartalom

A rugalmas skálázási szolgáltatási szinttel kapcsolatos további információkért lásd rugalmas skálázású szolgáltatási szint.