Azure SQL Database – Rugalmas skálázással kapcsolatos gyakori kérdések

A rugalmas skálázású adatbázisok az SQL Database-ben található adatbázisok, amelyeket a rugalmas skálázású kibővített tárolási technológia biztosít. A rugalmas skálázású adatbázisok legfeljebb 100 TB-nyi adatot támogatnak, nagy átviteli sebességet és jó teljesítményt biztosítanak, valamint gyors méretezéssel igazodnak a számításifeladat-igényekhez. A Csatlakozás ivity, a lekérdezésfeldolgozás, az adatbázismotor funkciói stb. az Azure SQL Database bármely más adatbázisához hasonlóan működnek.

A rugalmas skálázási szolgáltatási szint csak az Azure SQL Database-ben virtuálismag-alapú vásárlási modellt használó önálló adatbázisok esetében érhető el. A DTU-alapú vásárlási modellben nem érhető el.

A virtuális magalapú szolgáltatási szintek az adatbázis rendelkezésre állása és tárolási típusa, teljesítménye és maximális tárterületmérete alapján vannak megkülönböztetve az erőforrás-korlát összehasonlításában leírtak szerint.

A rugalmas skálázási szolgáltatási szint azoknak az ügyfeleknek való, akiknek jobb teljesítményre, nagyobb rendelkezésre állásra, gyors biztonsági mentésre és visszaállításra és/vagy gyors tárolóra és skálázható számítási kapacitásra van szükségük. Ez magában foglalja azokat az ügyfeleket, akik az alkalmazásaik modernizálása céljából áttérnek a felhőbe, és azokat is, akik már használnak más szolgáltatási szinteket az Azure SQL Database-ben. A rugalmas skálázás a következőket nyújtja:

• Az adatbázis mérete legfeljebb 100 TB.
• 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 naplóteljesítmény az adatbázis méretétől és a virtuális magok számától függetlenül.
• Olvasási felskálázás egy vagy több írásvédett replikával, amely olvasási kiszervezéshez vagy készenléti adatbázisként használható.
• A számítás gyors vertikális felskálázása állandó idő alatt a nagy terhelés hatékonyabb kezeléséhez, majd vertikális leskálázás állandó 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 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 a kiszolgálón található önálló és készletezett adatbázisokra vonatkozó SQL Database-erőforráskorlátokat.

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-le ská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ó távoli, a vertikális felskálázás és a leskálázás nem adatművelet mérete.

  A kiszolgáló nélküli számítás támogatása automatikus felskálázást és vertikális leskálázást biztosít, a számítás számlázása pedig a használat alapján történik.

• Horizontális fel- és kiskálázás

  A rugalmas skálázással háromféle másodlagos replika használható a vertikális felskálázási, magas rendelkezésre állási és georeplikációs követelmények olvasására. Ide tartoznak az alábbiak:

  • Legfeljebb négy magas rendelkezésre állású replika, amelyek számítási mérete megegyezik az elsődlegessel. Ezek gyors készenléti replikaként szolgálnak az elsődleges feladatátvételhez. Használhatja őket az olvasási számítási feladatok kiszervezésére is az elsődlegesből.
  • Legfeljebb 30 elnevezett replika rendelkezik ugyanazzal vagy más számítási méretekkel, mint az elsődleges, a különböző olvasási felskálázási forgatókönyvek kiszolgálásához.
  • Földrajzi replika egy másik Azure-régióban, amely védelmet nyújt a regionális kimaradások ellen, és lehetővé teszi a földrajzi olvasási felskálázást.

Igen, válthat.

Nem, az alkalmazásprogramozási modell ugyanaz marad, mint bármely más MSSQL-adatbázis esetében. A szokásos módon használja a kapcsolati sztring és a rugalmas skálázású adatbázissal való interakció egyéb szokásos módjait. A rugalmas skálázás használata után az alkalmazás kihasználhatja az olyan funkciók előnyeit, mint a másodlagos replikák.

Az elsődleges replikán az alapértelmezett tranzakcióelkülönítési szint az RCSI (Read Committed Snapshot Isolation). Az Olvasási felskálázás másodlagos replikákban az alapértelmezett elkülönítési szint a Pillanatkép. Ez ugyanaz, mint bármely más Azure SQL-adatbázisban.

Igen, az Azure Hybrid Benefit csak a kiépített számítási szinten érhető el rugalmas skálázáshoz. Minden SQL Server Standard mag egy rugalmas skálázású virtuális magra képezhető le. Minden SQL Server Enterprise-mag négy rugalmas skálázású virtuális magra képezhető le. Nincs szükség SQL-licencre a másodlagos replikákhoz. Az Azure Hybrid Benefit árát a rendszer automatikusan alkalmazza az olvasási felskálázási (másodlagos) replikákra. A használaton alapuló alternatív számlázási lehetőségért tekintse meg a kiszolgáló nélküli számítást . Megjegyzés: Az SQL Database Rugalmas skálázás egyszerűsített díjszabása hamarosan elérhető lesz. A részletekért tekintse át a rugalmas skálázási díjszabás blogját .

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 az SQL Servert adattárházként használó interaktív elemzési lekérdezéseket futtat, 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 100 TB-ot) is üzemeltethet alacsonyabb költséggel, és minimális T-SQL-kódmódosításokkal rugalmas skálázásba migrálhatja az SQL Server-adattárház számítási feladatait.

Ha nagy léptékű adatelemzést futtat összetett lekérdezésekkel és 100 MB/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 használatával, az Azure Synapse Analytics lehet a legjobb választás.

Jelenleg nem. A számítást és a replikák számát azonban leskálázhatja, hogy csökkentse a költségeket a nem idő alatt, vagy kiszolgáló nélküli használatával automatikusan skálázhatja a számítást a használat alapján.

Olvasási számítási feladatokhoz létrehozhat egy nevesített replikát , amely nagyobb számítási mérettel (több maggal és memóriával) rendelkezik, mint az elsődleges. Az elérhető számítási méretekkel kapcsolatos további információkért lásd : Rugalmas skálázású tárolás és számítási méretek.

Az olvasási számítási feladatok esetében ez nevesített replikákkal érhető el.

A másodlagos HA-replikák számát 0 és 4 között skálázhatja az Azure Portal vagy a REST API használatával. Emellett akár 30 elnevezett replikát is létrehozhat számos olvasási felskálázási forgatókönyvhöz.

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 leállt, a rendszer automatikusan létrehoz egy új replikát adatvesztés nélkül.

Ha azonban csak az elsődleges replika található, a feladatátvétel után egy-két percig is eltarthat egy új replika létrehozása, szemben a másodlagos HA-replika rendelkezésre állásának másodpercével. 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.

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 növekedhet a hosszú ideig futó tranzakciók miatt, vagy azért, mert az adatrögzítés feldolgozása 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ógenerálási arány azonban szabályozható a folyamatos agresszív írási számítási feladatok esetében. A naplók folyamatos létrehozásának csúcsértéke 100 MB/s.

Az 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 méret tempdb nem konfigurálható, és az Ön számára van felügyelve. Az adatbázis maximális tempdb méretének meghatározásához tekintse meg a 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 10 GB-os adattömbökben 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.

Szám Az adatfájlok automatikusan hozzáadódnak 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 szélesebb körben.

Szám

Jelenleg nem.

Igen, csakúgy, mint bármely más Azure SQL DB-adatbázisban. Ez magában foglalja a sor-, oldal- és oszlopcentrikus tömörítést.

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 használ az adatok adatfájlokon keresztüli elosztásához.

Igen. Az Azure SQL Database-ben meglévő adatbázisait rugalmas skálázásra helyezheti át. 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 rugalmas skálázásra.

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 lesz, ha az áthelyezés alacsony írási tevékenység időszakában történik.

Mintakód lekérése meglévő Azure SQL-adatbázisok rugalmas skálázásba való migrálásához az Azure Portalon, az Azure CLI-ben, a PowerShellben és a Transact-SQL-ben meglévő adatbázisok rugalmas skálázásba való migrálásában.

Ha a rugalmas skálázás nem felel meg az igényeiknek, az Általános célú szolgáltatásszintre való visszatelepítés lehetővé teszi, hogy az Azure SQL Database-ben meglévő adatbázist a rugalmas skálázási szolgáltatási szintre migrált ügyfelek visszaléphessenek. 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 lesz, ha alacsony írási tevékenység alatt történik. További információ a fordított migrálás korlátozásairól.

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 az adatbázist egy másik szolgáltatási szintre (például üzletileg kritikus) szeretné migrálni, 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 az adatművelet mérete.

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

Megtudhatja, hogyan fordíthatja vissza a migrálást a rugalmas skálázásról, beleértve a fordított migrálásra és az érintett biztonsági mentési szabályzatokra vonatkozó korlátozásokat.

Igen. Az Azure SQL Database egyes funkciói még 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ásba való migrálás blokkolható, vagy ezek a funkciók az áttelepítés után leállnak. Azt várjuk, hogy ezek a korlátozások ideiglenesek lesznek. További részletekért lásd: 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 az Azure Database Migration Service-t, amely számos migrálási forgatókönyvet támogat.

A rugalmas skálázásba való 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óval minimálisra csökkentheti az állásidő-migrálást néhány TB méretű adatbázis esetében. 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 100 MB/s új/módosított adat felhasználására képes, 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 é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álhatja az Azure Data Factoryt, vagy használhat egy Spark-feladatot az Azure Databricksbenaz SQL Spark-összekötőjével. A Spark-összekötő az SQL-hez támogatja a tömeges beszúrást.

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

Az egyszerű helyreállítási vagy tömeges naplózási modell nem támogatott a rugalmas skálázásban. 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.

Szám A rugalmas skálázás szimmetrikus többfeldolgozós (SMP) architektúra, és nem egy nagymértékben párhuzamos feldolgozás (MPP) vagy több fő architektúra. Csak több replikát hozhat létre az írásvédett számítási feladatok vertikális felskálázásához.

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

Lásd az Azure SQL Database SLA-ját. Javasoljuk, hogy ha másodlagos HA-replikákat adjon hozzá a kritikus számítási feladatokhoz. 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 rugalmas skálázás támogatja a zónaredundáns konfigurációt. A rugalmas skálázás zónaredundáns konfigurációjának engedélyezéséhez legalább egy másodlagos HA-replika és zónaredundáns vagy georedundáns tároló használata szükséges.

A rugalmas skálázású adatbázisok esetén nincs hagyományos teljes, különbségi és tranzakciónapló-alapú biztonsági mentés. 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ót aktuális állapotában őrzi meg a rendszer a konfigurált megőrzési időszakban. 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 tranzakciós konzisztens adatbázist eredményez anélkül, hogy az adatvesztés a megadott időponttól kezdve a megőrzési időszakon belül bekövetkezik. Valójában a rugalmas skálázású 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 redundanciának módosítása a visszaállítás kiadásakor hosszabb visszaállítási időt eredményezhet, mivel a visszaállítás az adatok mérete, ezért az idő arányos lesz az adatbázis méretével.

Szám 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. A georedundáns tárolás használata esetén a georedundáns visszaállítás teljes mértékben támogatott. Ez az új adatbázisok alapértelmezett beállítása. Az időponthoz kötött visszaállítástól eltérően a georedukció 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 lesz, ha az adatbázis a forrásadatbázis régiójával párosított Azure-régióban lesz visszaállítva .

Igen. A georeplikációs beállítás beállítható rugalmas skálázású adatbázisokhoz.

Szám 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 ki szeretné venni az adatokat egy rugalmas skálázású adatbázisból, bármilyen adatáthelyezési technológiával kinyerheti az adatokat, azaz 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 rögzített díjak alapjá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árterület-redundancia.

A biztonsági másolatok tárolási méretének mérésére vonatkozó részleteket az automatikus biztonsági mentések rögzítik.

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-t. A kiszolgáló nélküli számítási szinten a biztonsági mentés számlázása megegyezik a kiépített számítási szinttel.

A biztonsági mentés költségei magasabbak lesznek azon 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ára vonatkozó részleteket az automatikus biztonsági mentések rögzítik.

A tranzakciónapló átviteli sebességének korlátja 100 MB/s-ra van állítva bármilyen rugalmas skálázású 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.

Az IOPS és az IO késése a számítási feladatok mintáitól függően változhat. Ha a hozzáférő adatok gyorsítótárazva lesznek az RBPEX-ben a számítási replikán, hasonló IO-teljesítményt fog látni, mint üzletileg kritikus vagy Prémium szolgáltatási szinteken.

Szám 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 számítási feladatokat azonban szabályozni lehet az elsődlegesen, hogy lehetővé tegye a naplók másodlagos replikákra és lapkiszolgálókra való alkalmazását a felzárkózáshoz. Ez elkerüli a másodlagos replikák gyenge olvasási teljesítményét és a ha másodlagos replikára való feladatátvétel utáni hosszú helyreállítást.

Igen. A többi Azure SQL DB-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 olyan karbantartási időszakot , 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 SQL gyakori diagnosztikai és hibaelhárítási lépései érvényesek. A rugalmas skálázásra vonatkozó tárolási diagnosztikát az SQL Rugalmas skálázási teljesítmény hibaelhárítási diagnosztikái című témakörben találja.

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 a kiszolgáló nélküli rugalmas skálázási erőforráskorlátokat .

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.

Szám 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 számítási csomópontokon az adatbázis és az RBPEX gyorsítótár 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 és számítási méretek.

Szám Csak az elsődleges számítási replika fogad olvasási/írási kéréseket. A másodlagos számítási replikák csak írásvédett kérelmeket fogadnak el.

A rugalmas skálázás támogatja a magas rendelkezésre állású (HA) replikákat, az elnevezett replikákat és a georeplikákat. Részletekért tekintse meg a 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 az Azure Portal vagy a REST API használatával teheti meg.

Ezekhez a további írásvédett számítási replikákhoz a kapcsolati sztring ReadOnlytulajdonságának beállításával ApplicationIntent csatlakozhat. Ha vannak ilyenek ReadOnly , a rendszer automatikusan átirányítja a kijelölt kapcsolatokat az egyik másodlagos HA-replikára. További információ: Írásvédett replikák használata írásvédett lekérdezési számítási feladatok kiszervezéséhez.

A következő T-SQL-lekérdezést hajthatja végre: SELECT DATABASEPROPERTYEX ('<database_name>', 'Updateability'). Az eredmény az 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 az master adatbázisra.

Szám A másodlagos HA-replikákhoz csak a megadásával ApplicationIntent=ReadOnlycsatlakozhat. A nevesített replikákhoz azonban dedikált végpontokat is használhat.

Szám A rendszer egy írásvédett szándékú új kapcsolatot átirányít egy tetszőleges HA másodlagos replikára.

Nem a kiosztott számítási szinten. 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 másodlagos HA továbbra is automatikusan skálázható a konfigurált maximális magokra a feladatátvétel utáni szerepkörének megfelelően. Az elnevezett replikák lehetővé teszik az egyes replikák egymástól függetlenül történő skálázását.

Szám Az 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, beleértve tempdbaz elsődleges számítás méretét is. Az elnevezett replikáktempdb mérete a replika számítási méretének megfelelően van méretezve, így kisebb vagy nagyobb lehet, mint tempdb az elsődleges replikán.

Szám A rugalmas skálázású adatbázisok megosztott tárhellyel rendelkeznek, 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. Az ideiglenes adatok tárolásához továbbra is létrehozhat ideiglenes táblákat (#vagy ##előtaggal ellátott táblaneveket) minden másodlagos replikán. Az ideiglenes táblák írásvédettek.

Az adatok késése attól az időponttól kezdve, amikor egy tranzakció le van kötve az elsődlegesen, és a másodlagosan olvasható, az aktuális naplógenerálási sebességtől, a tranzakció méretétől, a replika terhelésé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 azonban 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élként az elsődleges replikához. Ha-replikákat adhat hozzá ehhez a célra.

Mivel minden elnevezett replika eltérő szolgáltatásiszint-célkitűzéssel rendelkezhet, és így különböző használati esetekhez használható, nincs beépített mód az elsődlegesnek küldött írásvédett forgalom irányítására 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 szeretne létrehozni, 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ájá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.

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 replika is szinkronizálva lesz az elsődlegessel a tranzakciónapló-szolgáltatáson keresztül. Ha egy elnevezett replika bármilyen okból nem tudja elég gyorsan felhasználni a tranzakciónaplót, elkezdi kérni az elsődleges replikát, hogy lassítsa (szabályozza) a naplógenerálást, 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 írási számítási feladatok teljesítményére az elsődlegesen. A helyzet elkerülése érdekében győződjön meg arról, hogy a nevesített replikák elegendő erőforrás -főként CPU-val rendelkeznek ahhoz, hogy a tranzakciónaplót késedelem nélkül feldolgozzák. Ha például az elsődleges számos adatváltozást dolgoz fel, javasoljuk, hogy legalább az elsődleges szolgáltatásszint-célkitűzéssel megegyező nevű replikákat használjon, hogy elkerülje a processzorok telítettségi szintjét a replikákon, és ezáltal az elsődlegest lassítsa.

A nevesített replikák a szokásos módon továbbra is elérhetők lesznek írásvédett hozzáféréshez.

Alapértelmezés szerint a nevesített replikák nem rendelkeznek saját HA-replikákkal. Egy elnevezett replika feladatátvételéhez először létre kell hoznia egy új replikát, amely általában körülbelül 1–2 percet vesz igénybe. Az elnevezett replikák azonban a HA-replikák által biztosított magasabb rendelkezésre állás és rövidebb feladatátvétel előnyeit is élvezhetik. Ha HA-replikákat szeretne hozzáadni egy elnevezett replikához, használhatja a paramétert ha-replicas az AZ CLI-vel, a paramétert HighAvailabilityReplicaCount a PowerShell-lel, vagy a highAvailabilityReplicaCount REST API-val rendelkező tulajdonságot. A HA-replikák száma beállítható egy elnevezett replika létrehozása során, és a névvel ellátott replika létrehozása után bármikor módosítható – csak az AZ CLI, a PowerShell vagy a REST API használatával. A névvel ellátott replikákHOZ tartozó HA-replikák díjszabása megegyezik a normál rugalmas skálázású adatbázisok HA replikáival.

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.