Resource management in Azure SQL Database

A következőre vonatkozik: Azure SQL Database

• Azure SQL Database logikai kiszolgáló
• Önálló Azure SQL Database-adatbázis
• Felügyelt Azure SQL-példány

Ez a cikk áttekintést nyújt az Azure SQL Database erőforrás-kezeléséről. Információt nyújt arról, hogy mi történik az erőforráskorlátok elérésekor, és ismerteti azokat az erőforrás-szabályozási mechanizmusokat, amelyek a korlátok kényszerítésére szolgálnak.

Az önálló adatbázisok tarifacsomagonkénti erőforráskorlátjai (más néven szolgáltatási célkitűzés) esetében tekintse meg a DTU-alapú egyadatbázis-erőforráskorlátokat vagy a virtuális magalapú egyadatbázis-erőforráskorlátokat. A rugalmas készlet erőforráskorlátjaiért tekintse meg a DTU-alapú rugalmas készlet erőforráskorlátait vagy a virtuális magalapú rugalmas készlet erőforráskorlátait. Az Azure Synapse Analytics dedikált SQL-készletkorlátjaiért tekintse meg a kapacitáskorlátokat , valamint a memória- és egyidejűségi korlátokat.

Megjegyzés:

A virtuálismag-vásárlási modell Gen5-hardverét standard sorozatúra (Gen5) nevezték át.

Tipp.

Az Azure Synapse Analytics dedikált SQL-készletkorlátjaiért tekintse meg a kapacitáskorlátokat , valamint a memória- és egyidejűségi korlátokat.

Logikai kiszolgáló korlátai

Resource	Limit
Adatbázisok logikai kiszolgálónként	5000
Logikai kiszolgálók alapértelmezett száma előfizetésenként egy régióban	20
Logikai kiszolgálók maximális száma előfizetésenként egy régióban	250
DTU/eDTU-kvóta 1 logikai kiszolgálónként	54,000
virtuális magkvóta 1 logikai kiszolgálónként 2	540
Rugalmas készletek maximális száma logikai kiszolgálónként	A DTU-k vagy virtuális magok száma korlátozott. Ha például minden készlet 1000 DTU, akkor a kiszolgáló 54 készletet támogat.

¹ A DTU vásárlási modellel kiépített adatbázisok és rugalmas készletek szintén beleszámítanak a virtuális mag kvótába, és fordítva. Minden felhasznált virtuális mag egyenértékű a kiszolgálószintű kvótához felhasznált 100 DTU-val.

² Ez magában foglalja a kiépített számítási adatbázisokhoz/rugalmas készletekhez konfigurált virtuális magokat és a kiszolgáló nélküli adatbázisokhoz konfigurált "maximális virtuális magokat".

Fontos

Ahogy az adatbázisok száma megközelíti a logikai kiszolgálónkénti korlátot, a következők fordulhatnak elő:

• Az adatbázison futó lekérdezések késésének master növelése. Ide tartoznak az erőforrás-kihasználtság statisztikáinak nézetei, például sys.resource_statsa .
• A felügyeleti műveletek késésének növelése és a portálnézetek renderelése, amelyek magukban foglalják a kiszolgálón lévő adatbázisok számbavételét.

Megjegyzés:

Ha az alapértelmezett számnál több DTU/eDTU-kvótát, virtuális magkvótát vagy több logikai kiszolgálót szeretne beszerezni, küldjön egy új támogatási kérelmet az Azure Portalon. További információ: Kvótanövelés kérése az Azure SQL Database-hez.

Mi történik az erőforráskorlátok elérésekor?

Számítási PROCESSZOR

Amikor az adatbázis-számítási processzor kihasználtsága magasvá válik, a lekérdezések késése nő, és a lekérdezések akár időtúllépést is okozhatnak. Ilyen feltételek mellett előfordulhat, hogy a szolgáltatás várólistára állítja a lekérdezéseket, és erőforrásokat biztosít a végrehajtáshoz, amint az erőforrások ingyenessé válnak. Ha magas számítási kihasználtságot észlel, a kockázatcsökkentési lehetőségek a következők:

• Az adatbázis vagy a rugalmas készlet számítási méretének növelése, hogy az adatbázis több számítási erőforrást biztosítson. Lásd: Önálló adatbázis-erőforrások skálázása és rugalmas készleterőforrások méretezése.
• Lekérdezések optimalizálása az egyes lekérdezések CPU-erőforrás-kihasználtságának csökkentése érdekében. További információkért lásd: Lekérdezések finomhangolása/Javaslatok.

Storage

Ha a felhasznált adatterület eléri a maximális adatméretkorlátot az adatbázis szintjén vagy a rugalmas készlet szintjén, az adatméretet növelő beszúrások és frissítések meghiúsulnak, és az ügyfelek hibaüzenetet kapnak. Standard kiadás LECT és DELETE utasítások változatlanok maradnak.

A Prémium és üzletileg kritikus szolgáltatási szinteken az ügyfelek hibaüzenetet is kapnak, ha az adatok, tranzakciónaplók és tempdb egyetlen adatbázis vagy rugalmas készlet együttes tárolási felhasználása meghaladja a maximális helyi tárterület-méretet. További információ: Tárhelyszabályozás.

Ha magas tárterület-kihasználtságot észlel, a kockázatcsökkentési lehetőségek a következők:

• Növelje az adatbázis vagy a rugalmas készlet maximális adatméretét, vagy vertikálisan felskálázható egy szolgáltatási célkitűzésre magasabb maximális adatméretkorláttal. Lásd: Önálló adatbázis-erőforrások skálázása és rugalmas készleterőforrások méretezése.
• Ha az adatbázis rugalmas készletben található, akkor másik lehetőségként az adatbázis áthelyezhető a készleten kívülre, hogy a tárterülete ne legyen megosztva más adatbázisokkal.
• Az adatbázis zsugorítása a nem használt terület visszaszerzéséhez. Rugalmas készletekben az adatbázisok zsugorítása több tárhelyet biztosít a készlet más adatbázisai számára. További információ: Fájltér kezelése az Azure SQL Database-ben.
• Ellenőrizze, hogy a magas helykihasználtság az állandó verziótár (PVS) méretének megugrása miatt van-e. A PVS minden adatbázis része, és a gyorsított adatbázis-helyreállítás megvalósítására szolgál. Az aktuális PVS-méret meghatározásához tekintse meg a PVS hibaelhárítását. A nagy PVS-méret gyakori oka egy olyan tranzakció, amely hosszú ideig (órákig) nyitva van, megakadályozva a sor régebbi verzióinak törlését a PVS-ben.
• A prémium szintű adatbázisok és rugalmas készletek, valamint a nagy mennyiségű tárterületet használó üzletileg kritikus szolgáltatási szintek esetén előfordulhat, hogy helykihasználtság-hiba jelentkezik, annak ellenére, hogy az adatbázisban vagy a rugalmas készletben használt terület nem éri el a maximális adatméretkorlátot. Ez akkor fordulhat elő, ha tempdb a tranzakciós naplófájlok nagy mennyiségű tárterületet használnak fel a maximális helyi tárterület-korlát felé. Az adatbázis vagy a rugalmas készlet feladatátvétele a kezdeti kisebb méretre való visszaállításhoz tempdb , vagy a tranzakciónapló zsugorítása a helyi tárolóhasználat csökkentése érdekében.

Munkamenetek, feldolgozók és kérések

A munkamenetek, a feldolgozók és a kérések a következőképpen vannak definiálva:

• A munkamenet az adatbázismotorhoz csatlakoztatott folyamatot jelöli.
• A kérés egy lekérdezés vagy köteg logikai ábrázolása. A kérést egy munkamenethez csatlakoztatott ügyfél küldi el. Idővel több kérés is kibocsátható ugyanazon a munkameneten.
• A feldolgozói szál, más néven feldolgozó vagy szál az operációs rendszer szálának logikai ábrázolása. A kérések több feldolgozóval is rendelkezhetnek, ha párhuzamos lekérdezés-végrehajtási tervvel hajtják végre, vagy egyetlen feldolgozóval, ha soros (egyszálas) végrehajtási tervvel hajtják végre. A feldolgozóknak a kéréseken kívül is támogatniuk kell a tevékenységeket: például egy feldolgozónak fel kell dolgoznia egy bejelentkezési kérést, amikor egy munkamenet csatlakozik.

Ezekről a fogalmakról további információt a szál- és feladatarchitektúra útmutatójában talál.

A feldolgozók maximális számát a szolgáltatási szint és a számítási méret határozza meg. New requests are rejected when session or worker limits are reached, and clients receive an error message. Bár a kapcsolatok számát az alkalmazás szabályozhatja, az egyidejű feldolgozók számát gyakran nehezebb megbecsülni és szabályozni. Ez különösen igaz a csúcsterhelési időszakokban, amikor az adatbázis erőforráskorlátai elérik, és a feldolgozók halmozódnak fel a hosszabb ideig futó lekérdezések, a nagy blokkoló láncok vagy a lekérdezések túlzott párhuzamossága miatt.

Megjegyzés:

Az Azure SQL Database kezdeti ajánlata csak egyszálas lekérdezéseket támogatott. Abban az időben a kérelmek száma mindig megegyezett a munkavállalók számával. Az Azure SQL Database 10928-ban megjelenő hibaüzenete a "Az adatbázis kérelemkorlátja N , és elérte" szöveget tartalmazza a visszamenőleges kompatibilitás érdekében. Az elért korlát valójában a feldolgozók számára vonatkozik. Ha a max. párhuzamossági fok (MAXDOP) értéke nulla vagy egynél nagyobb, a dolgozók száma sokkal magasabb lehet, mint a kérelmek száma, és a korlát sokkal hamarabb érhető el, mint amikor a MAXDOP értéke egy. További információ az erőforrás-szabályozási hibák 10928-ás hibájáról.

A munkavégzők vagy munkamenetek korlátainak megközelítését vagy túllépését az alábbiakkal csökkentheti:

• Az adatbázis vagy a rugalmas készlet szolgáltatási szintjének vagy számítási méretének növelése. Lásd: Önálló adatbázis-erőforrások skálázása és rugalmas készleterőforrások méretezése.
• Lekérdezések optimalizálása az erőforrás-kihasználtság csökkentése érdekében, ha a megnövekedett feldolgozók oka a számítási erőforrásokért való versengés. További információkért lásd: Lekérdezések finomhangolása/Javaslatok.
• A lekérdezési számítási feladat optimalizálása az előfordulások számának és a lekérdezésblokkolás időtartamának csökkentése érdekében. További információ: Az Azure SQL blokkolási problémáinak ismertetése és megoldása.
• Szükség esetén csökkentse a MAXDOP-beállítást .

Az Azure SQL Database munkavégző és munkamenetkorlátainak megkeresése szolgáltatási szint és számítási méret szerint:

• Resource limits for single databases using the vCore purchasing model
• Resource limits for elastic pools using the vCore purchasing model
• Resource limits for single databases using the DTU purchasing model
• Rugalmas készletek erőforráskorlátai a DTU vásárlási modell használatával

További információ az erőforrás-szabályozási hibák munkamenet- vagy feldolgozókorlátjaival kapcsolatos hibák elhárításáról.

Külső kapcsolatok

A sp_invoke_external_rest_endpoint keresztül végzett külső végpontokhoz való egyidejű kapcsolatok száma a feldolgozószálak 10%-ára van leképezve, legfeljebb 150 feldolgozó kemény korlátjával.

Memory

Más erőforrásoktól (PROCESSZOR, feldolgozók, tároló) eltérően a memóriakorlát elérése nem befolyásolja negatívan a lekérdezés teljesítményét, és nem okoz hibákat és hibákat. A Memóriakezelési architektúra útmutatójában részletesen ismertetett módon az adatbázismotor gyakran az összes rendelkezésre álló memóriát használja kialakítás szerint. A memória elsősorban az adatok gyorsítótárazására szolgál, így elkerülhető a lassabb tárterület-hozzáférés. A memória nagy kihasználtsága tehát általában javítja a lekérdezi teljesítményt, mivel a memória olvasása gyorsabb, mint a táré.

Az adatbázismotor indítása után, amikor a számítási feladat elkezd adatokat olvasni a tárolóból, az adatbázismotor agresszíven gyorsítótárazza az adatokat a memóriában. A kezdeti felfutási időszak után gyakori és várható, hogy a avg_memory_usage_percent sys.dm_db_resource_stats sql_instance_memory_percentoszlopai és avg_instance_memory_percent az Azure Monitor metrika közel 100%-os lesz, különösen az olyan adatbázisok esetében, amelyek nem tétlenek, és nem férnek el teljesen a memóriában.

Megjegyzés:

A sql_instance_memory_percent metrika az adatbázismotor teljes memóriahasználatát tükrözi. Ez a metrika akkor sem éri el a 100%-ot, ha nagy intenzitású számítási feladatok futnak. Ennek az az oka, hogy a rendelkezésre álló memória egy kis része az adatgyorsítótártól eltérő kritikus memóriafoglalásokhoz van fenntartva, például szálvermekhez és végrehajtható modulokhoz.

Besides the data cache, memory is used in other components of the database engine. Ha a memóriaigény és az adatgyorsítótár az összes rendelkezésre álló memóriát felhasználta, az adatbázismotor csökkenti az adatgyorsítótár méretét, hogy a memória más összetevők számára is elérhetővé legyen, és dinamikusan növeli az adatgyorsítótárat, amikor más összetevők felszabadítják a memóriát.

Ritka esetekben egy megfelelően nagy igényű számítási feladat előidézheti, hogy a memória nem elégséges, ez pedig memóriahiány miatti hibákhoz vezet. A memóriakihasználtság bármely szintjén 0% és 100% közötti memóriahiba fordulhat elő. A memóriakimaradási hibák nagyobb valószínűséggel fordulnak elő kisebb számítási méretekben, amelyek arányosan kisebb memóriakorlátokkal rendelkeznek, és /vagy olyan számítási feladatok esetén, amelyek több memóriát használnak a lekérdezések feldolgozásához, például sűrű rugalmas készletekben.

Ha memóriahiba lépett fel, a kockázatcsökkentési lehetőségek a következők:

• Tekintse át az OOM-feltétel részleteit a sys.dm_os_out_of_memory_events.
• Az adatbázis vagy a rugalmas készlet szolgáltatási szintjének vagy számítási méretének növelése. Lásd: Önálló adatbázis-erőforrások skálázása és rugalmas készleterőforrások méretezése.
• Lekérdezések és konfiguráció optimalizálása a memória kihasználtságának csökkentése érdekében. A gyakori megoldásokat az alábbi táblázat ismerteti.

Megoldás	Leírás
Reduce the size of memory grants	A memóriahasználati támogatásokkal kapcsolatos további információkért tekintse meg az SQL Server memóriatámogatási blogbejegyzését. A szélsőségesen nagy memóriabeli ideiglenes tárak elkerülésére bevett megoldás a statisztikák naprakészen tartása. Ez pontosabb becslést eredményez a lekérdezési motor memóriahasználatáról, elkerülve a nagy memóriakihasználtságokat. By default, in databases using compatibility level 140 and above, the database engine may automatically adjust memory grant size using Batch mode memory grant feedback. Hasonlóképpen, a 150-es és újabb kompatibilitási szintet használó adatbázisokban az adatbázismotor sor módú memória-visszaadási visszajelzést is használ a gyakoribb sormódú lekérdezésekhez. Ez a beépített funkció segít elkerülni a memóriakihasználtság miatti memóriakihasználtságokat.
Reduce the size of query plan cache	The database engine caches query plans in memory, to avoid compiling a query plan for every query execution. A csak egyszer használt gyorsítótárazási tervek által okozott lekérdezésterv-gyorsítótár-blob elkerülése érdekében mindenképpen használjon paraméteres lekérdezéseket, és fontolja meg OPTIMIZE_FOR_AD_HOC_WORKLOADS adatbázis-hatókörű konfiguráció engedélyezését.
Reduce the size of lock memory	The database engine uses memory for locks. When possible, avoid large transactions that may acquire a large number of locks and cause high lock memory consumption.

Erőforrás-felhasználás felhasználói számítási feladatok és belső folyamatok szerint

Az Azure SQL Database olyan alapvető szolgáltatásfunkciók implementálásához igényel számítási erőforrásokat, mint a magas rendelkezésre állás és vészhelyreállítás, az adatbázis biztonsági mentése és visszaállítása, a monitorozás, a lekérdezéstár, az automatikus hangolás stb. A rendszer erőforrás-szabályozási mechanizmusokkal félretei a belső folyamatok teljes erőforrásainak egy korlátozott részét, így a többi erőforrás elérhetővé válik a felhasználói számítási feladatok számára. Amikor a belső folyamatok nem használnak számítási erőforrásokat, a rendszer elérhetővé teszi őket a felhasználói számítási feladatok számára.

A felhasználói számítási feladatok és belső folyamatok teljes processzor- és memóriahasználatát a rendszer a sys.dm_db_resource_stats és sys.resource_statsnézetekben, illetve oszlopokban avg_instance_cpu_percentavg_instance_memory_percent jelenti. Ezek az adatok a készlet szintjén lévő önálló adatbázisok és rugalmas készletek esetében az Azure Monitor és sql_instance_memory_percent az sql_instance_cpu_percent Azure Monitor metrikái alapján is jelentésre kerülnek.

Megjegyzés:

Az sql_instance_cpu_percent és sql_instance_memory_percent az Azure Monitor-metrikák 2023 júliusa óta érhetők el. Ezek teljes mértékben egyenértékűek a korábban elérhető sqlserver_process_core_percent és sqlserver_process_memory_percent a metrikákkal. Az utóbbi két metrika továbbra is elérhető marad, de a jövőben el lesz távolítva. Az adatbázis-figyelés megszakításának elkerülése érdekében ne használja a régebbi metrikákat.

Ezek a metrikák nem érhetők el az alapszintű, S1 és S2 szolgáltatási célkitűzéseket használó adatbázisokhoz. Ugyanezek az adatok az alább hivatkozott dinamikus felügyeleti nézetekben érhetők el.

A felhasználói számítási feladatok processzor- és memóriahasználata az egyes adatbázisokban a sys.dm_db_resource_stats és sys.resource_statsnézetekben, illetve oszlopokban avg_cpu_percentavg_memory_usage_percent történik. Rugalmas készletek esetén a készletszintű erőforrás-felhasználást a rendszer sys.elastic_pool_resource_stats nézetben (korábbi jelentéskészítési forgatókönyvek esetén) és sys.dm_elastic_pool_resource_stats valós idejű monitorozás céljából jelenti. A felhasználói számítási feladatok processzorhasználatát az cpu_percent Azure Monitor metrikáján keresztül is jelenti a rendszer az önálló adatbázisokhoz és a rugalmas készletekhez a készlet szintjén.

A felhasználói számítási feladatok és belső folyamatok legutóbbi erőforrás-felhasználásának részletesebb lebontása a sys.dm_resource_governor_resource_pools_history_ex és sys.dm_resource_governor_workload_groups_history_ex nézetekben történik. Az ezekben a nézetekben hivatkozott erőforráskészletekkel és számítási feladatcsoportokkal kapcsolatos részletekért lásd: Erőforrás-szabályozás. Ezek a nézetek a felhasználói számítási feladatok, valamint a kapcsolódó erőforráskészletek és számítási feladatok csoportjaiban lévő konkrét belső folyamatok erőforrás-kihasználtságáról nyújtanak jelentést.

Tipp.

A számítási feladatok teljesítményének monitorozása vagy hibaelhárítása során fontos figyelembe venni a felhasználói processzorhasználatot (), valamint a felhasználói számítási feladatok és a belső folyamatok (avg_instance_cpu_percent,sql_instance_cpu_percent) teljes PROCESSZORhasználatát is. cpu_percentavg_cpu_percent A teljesítmény észrevehetően befolyásolható, ha ezen metrikák bármelyike a 70–100%-os tartományban van.

A felhasználói CPU-használat százalékos értékként van meghatározva a felhasználói számítási feladatok cpu-korlátja felé az egyes szolgáltatási célkitűzésekben. Hasonlóképpen, a teljes processzorhasználat az összes számítási feladat cpu-korlátja felé irányuló százalékos értékként van definiálva. Mivel a két korlát eltérő, a felhasználó és a teljes CPU-használat különböző skálákon van mérve, és nem hasonlítható össze közvetlenül egymással.

Ha a felhasználói CPU-használat eléri a 100%-ot, az azt jelenti, hogy a felhasználói számítási feladat teljes mértékben használja a kiválasztott szolgáltatási célkitűzésben rendelkezésére álló processzorkapacitást, még akkor is, ha a teljes processzorhasználat 100% alatt marad.

Amikor a teljes CPU-használat eléri a 70–100%-os tartományt, a felhasználói számítási feladatok átviteli sebességének és a lekérdezések késésének növekedése látható, még akkor is, ha a felhasználói CPU-használat jelentősen 100% alatt marad. Ez nagyobb valószínűséggel fordul elő, ha kisebb szolgáltatási célkitűzéseket használ a számítási erőforrások mérsékelt lefoglalásával, de viszonylag intenzív felhasználói számítási feladatok, például sűrű rugalmas készletek esetén. Ez kisebb szolgáltatási célkitűzések esetén is előfordulhat, ha a belső folyamatok ideiglenesen további erőforrásokat igényelnek, például az adatbázis új replikája létrehozásakor vagy az adatbázis biztonsági mentésekor.

Hasonlóképpen, ha a felhasználói CPU-használat eléri a 70–100%-os tartományt, a felhasználói számítási feladatok átviteli sebessége ellaposodik, és a lekérdezések késése nő, annak ellenére , hogy a teljes processzorhasználat jóval a korlátja alatt lehet.

Ha a felhasználói CPU-használat vagy a teljes processzorhasználat magas, a kockázatcsökkentési lehetőségek megegyeznek a Számítási PROCESSZOR szakaszban leírtakkal, és tartalmazzák a szolgáltatás célkitűzésének növelését és/vagy a felhasználói számítási feladatok optimalizálását.

Megjegyzés:

Még egy teljesen tétlen adatbázis vagy rugalmas készlet esetén sem nulla a teljes processzorhasználat a háttéradatbázis-motor tevékenységei miatt. Az adott háttértevékenységtől, a számítási mérettől és a korábbi felhasználói számítási feladatoktól függően széles körben ingadozhat.

Erőforrások szabályozása

Az erőforráskorlátok érvényre juttatásához az Azure SQL Database egy SQL Server Resource Governor-alapú erőforrás-szabályozási implementációt használ, amelyet módosítottak és kiterjesztettek a felhőben való futtatásra. Az SQL Database-ben több erőforráskészlet és számítási feladatcsoport, valamint a készlet és a csoport szintjén beállított erőforráskorlátok kiegyensúlyozott, szolgáltatásként nyújtott adatbázist biztosítanak. A felhasználói számítási feladatok és a belső számítási feladatok külön erőforráskészletek és számítási feladatok csoportjaiba vannak besorolva. Az elsődleges és olvasható másodlagos replikák felhasználói számítási feladatai, beleértve a georeplikákat is, az erőforráskészletbe és UserPrimaryGroup.DBId[N] a SloSharedPool1 számítási feladatok csoportjaiba vannak besorolva, ahol [N] az adatbázis-azonosító értéke áll. Emellett több erőforráskészlet és számítási feladatcsoport is létezik a különböző belső számítási feladatokhoz.

A Resource Governor az adatbázismotor erőforrásainak szabályozása mellett az Azure SQL Database windowsos feladatobjektumokat is használ a folyamatszintű erőforrás-szabályozáshoz, a Windows File Server Resource Managert (FSRM) pedig a tárkvóta-kezeléshez.

Az Azure SQL Database erőforrás-szabályozása hierarchikus jellegű. A korlátokat felülről lefelé az operációs rendszer szintjén és a tárterület szintjén kényszeríti ki az operációs rendszer erőforrás-szabályozási mechanizmusai és erőforrás-kormányzója, majd az erőforráskészlet szintjén a Resource Governor, majd a számítási feladatcsoport szintjén a Resource Governor használatával. Az aktuális adatbázisra vagy rugalmas készletre vonatkozó erőforrás-szabályozási korlátok sys.dm_user_db_resource_governance nézetben jelennek meg.

Adatok I/O-szabályozása

Az adat-I/O-szabályozás az Azure SQL Database-ben a fizikai I/O olvasásának és írásának az adatbázis adatfájljaira való korlátozására szolgál. Az IOPS-korlátok az egyes szolgáltatási szintekre vannak beállítva a "zajos szomszéd" hatás minimalizálása, az erőforrás-kiosztás méltányosságának biztosítása a több-bérlős szolgáltatásban, valamint a mögöttes hardver és tároló képességeinek megfelelőek maradnak.

Az önálló adatbázisok esetében a számítási feladatok csoportkorlátjai az összes tároló I/O-ra vonatkoznak az adatbázison. Rugalmas készletek esetén a számítási feladatok csoportkorlátjai a készlet minden adatbázisára vonatkoznak. Emellett az erőforráskészlet korlátja a rugalmas készlet halmozott I/O-jára is vonatkozik. Az tempdbI/O-ban a számítási feladatok csoportkorlátjai vonatkoznak, kivéve az alapszintű, a standard és az általános célú szolgáltatási szintet, ahol magasabb tempdb I/O-korlátok vonatkoznak. Előfordulhat, hogy az erőforráskészlet korlátait a számítási feladat nem éri el egy adatbázison (akár önálló, akár készletezett), mivel a számítási feladatcsoport korlátai alacsonyabbak az erőforráskészlet korlátainál, és hamarabb korlátozzák az IOPS/átviteli sebességet. A készletkorlátokat azonban elérheti az egyesített számítási feladat az ugyanabban a készletben lévő több adatbázisra vonatkozóan.

Ha például egy lekérdezés 1000 IOPS-t hoz létre I/O-erőforrás-szabályozás nélkül, de a számítási feladatcsoport maximális IOPS-korlátja 900 IOPS-ra van állítva, a lekérdezés nem tud 900-nál több IOPS-t létrehozni. Ha azonban az erőforráskészlet maximális IOPS-korlátja 1500 IOPS, és az erőforráskészlethez társított összes számítási feladatcsoport teljes I/O-értéke meghaladja az 1500 IOPS-t, akkor ugyanannak a lekérdezésnek az I/O-értéke a munkacsoport 900 IOPS-korlátja alá csökkenhet.

Az sys.dm_user_db_resource_governance nézet által visszaadott IOPS- és átviteli sebesség maximális értékei korlátokként/korlátként működnek, nem pedig garanciaként. Továbbá az erőforrás-szabályozás nem garantálja a tárolási késést. Egy adott felhasználói számítási feladat számára elérhető legjobb késés, IOPS és átviteli sebesség nem csak az I/O erőforrás-szabályozási korlátoktól, hanem a használt I/O-méretek kombinációjától és a mögöttes tároló képességeitől is függ. Az SQL Database olyan I/O-műveleteket használ, amelyek mérete 512 bájt és 4 MB között változik. Az IOPS-korlátok érvényre juttatása érdekében minden I/O-t számba kell venni a méretétől függetlenül, kivéve az Azure Storage-beli adatfájlokat tartalmazó adatbázisokat. Ebben az esetben a 256 KB-nál nagyobb I/O-k több 256 KB-os I/O-ként vannak elszámolva, hogy igazodjanak az Azure Storage I/O könyveléséhez.

Az Azure Storage-ban adatfájlokat használó alapszintű, standard és általános célú adatbázisok esetében előfordulhat, hogy az érték nem érhető el, primary_group_max_io ha egy adatbázis nem rendelkezik elegendő adatfájllal az IOPS összegző megadásához, vagy ha az adatok nem egyenletesen vannak elosztva a fájlok között, vagy ha az alapul szolgáló blobok teljesítményszintje korlátozza az IOPS/átviteli sebességet az erőforrás-szabályozási korlátok alatt. Hasonlóképpen, a tranzakciók gyakori véglegesítése által generált kis napló I/O-műveletek esetén előfordulhat, hogy az primary_max_log_rate érték nem érhető el egy számítási feladat számára a mögöttes Azure Storage-blob IOPS-korlátja miatt. Az Azure Premium Storage-t használó adatbázisok esetében az Azure SQL Database elegendően nagy tárolóblobokat használ a szükséges IOPS/átviteli sebesség beszerzéséhez, az adatbázis méretétől függetlenül. Nagyobb adatbázisok esetén több adatfájl jön létre a teljes IOPS/átviteli sebesség növeléséhez.

A sys.dm_db_resource_stats, sys.resource_stats, sys.dm_elastic_pool_resource_stats és sys.elastic_pool_resource_stats nézetekben jelentett erőforrás-kihasználtsági értékeket avg_data_io_percentavg_log_write_percenta rendszer a maximális erőforrás-szabályozási korlátok százalékában számítja ki. Ezért ha az erőforrás-szabályozási korláton kívül más tényezők is korlátozzák az IOPS/átviteli sebességet, az IOPS/átviteli sebesség elsimulását és a késések növekedését tapasztalhatja a számítási feladat növekedésével, annak ellenére, hogy a jelentett erőforrás-kihasználtság továbbra is 100% alatt marad.

Az IOPS olvasási és írási sebességének, az adatbázisfájlonkénti átviteli sebességnek és késésnek a figyeléséhez használja a sys.dm_io_virtual_file_stats() függvényt. Ez a függvény az összes I/O-t az adatbázison keresztül jeleníti meg, beleértve a háttérbeli I/O-t is, amely nem tartozik az avg_data_io_percentadatbázisba, de IOPS-t és az alapul szolgáló tároló átviteli sebességét használja, és hatással lehet a megfigyelt tárolási késésre. A függvény további késéseket jelez, amelyeket az I/O-erőforrás-szabályozás az olvasások és írások esetében, illetve az io_stall_queued_read_msio_stall_queued_write_ms oszlopokban okozhat.

Tranzakciónaplók sebességszabályozása

A tranzakciónaplók sebességszabályozása az Azure SQL Database-ben a számítási feladatok, például a tömeges beszúrás, a Standard kiadás LECT INTO és az index buildek magas betöltési arányának korlátozására szolgál. Ezeket a korlátokat a rendszer az alszekundum szintjén követi és érvényesíti a naplórekordok létrehozásának sebességére, és korlátozza az átviteli sebességet attól függetlenül, hogy hány I/O adható ki az adatfájlokhoz. A tranzakciónapló-létrehozási arányok jelenleg lineárisan skálázhatók egy olyan pontra, amely hardverfüggő és szolgáltatásszint-függő.

A naplózási arányok úgy vannak beállítva, hogy különböző forgatókönyvekben elérhetőek és fenntarthatók legyenek, míg az általános rendszer minimális hatással lehet a felhasználói terhelésre. A naplók sebességszabályozása biztosítja, hogy a tranzakciónapló biztonsági mentései a közzétett helyreállíthatósági SLA-kon belül maradjanak. Ez a szabályozás megakadályozza a másodlagos replikák túlzott leállását is, amely egyébként a vártnál hosszabb állásidőt eredményezhet a feladatátvétel során.

A tranzakciós naplófájlok tényleges fizikai I/O-jai nincsenek szabályozva vagy korlátozva. A naplórekordok létrehozásakor a rendszer minden műveletet kiértékel és kiértékel, hogy késleltetni kell-e a maximálisan kívánt naplósebességet (MB/s másodpercenként). A késések nem lesznek hozzáadva, amikor a naplórekordok ki vannak ürítve a tárolóba, hanem a naplósebesség szabályozása lesz alkalmazva a naplósebesség létrehozásakor.

A futtatáskor érvényes naplólétrehozási arányokat a visszajelzési mechanizmusok is befolyásolhatják, ideiglenesen csökkentve az engedélyezett naplók sebességét, hogy a rendszer stabilizálódhasson. A naplófájlterület kezelése, a naplótér kifogyott állapotainak és az adatreplikációs mechanizmusoknak a elkerülése ideiglenesen csökkentheti a teljes rendszerkorlátot.

A naplósebesség-szabályozó forgalomalakítása a következő várakozási típusokkal történik (a sys.dm_exec_requests és sys.dm_os_wait_stats nézetekben):

Várakozás típusa	Jegyzetek
LOG_RATE_GOVERNOR	Adatbázis-korlátozás
POOL_LOG_RATE_GOVERNOR	Készletkorlátozás
INSTANCE_LOG_RATE_GOVERNOR	Példányszint-korlátozás
HADR_THROTTLE_LOG_RATE_Standard kiadásND_RECV_QUEUE_SIZE	Visszajelzés-vezérlés, rendelkezésre állási csoport fizikai replikációja a Prémium/üzletileg kritikus nem tart lépést
HADR_THROTTLE_LOG_RATE_LOG_SIZE	Visszajelzés-vezérlés, sebességkorlátozás a naplóterület kiesésének elkerülése érdekében
HADR_THROTTLE_LOG_RATE_MISMATCHED_SLO	Georeplikációs visszajelzések szabályozása, a naplók sebességének korlátozása a magas adatkésés és a georeplikációk elérhetetlenségének elkerülése érdekében

Ha olyan naplósebesség-korlátot tapasztal, amely akadályozza a kívánt méretezhetőséget, vegye figyelembe a következő lehetőségeket:

• Vertikális felskálázás magasabb szolgáltatási szintre egy szolgáltatási szint maximális naplózási sebességének lekéréséhez, vagy váltás másik szolgáltatási szintre. A rugalmas skálázású szolgáltatási szint adatbázisonként 100 MB/s naplózási sebességet és rugalmas készletenként 125 MB/s-ot biztosít a választott szolgáltatási szinttől függetlenül.

  Megjegyzés:

  A rugalmas skálázás rugalmas készletei jelenleg előzetes verzióban érhetők el.

• If data being loaded is transient, such as staging data in an ETL process, it can be loaded into tempdb (which is minimally logged).

• For analytic scenarios, load into a clustered columnstore table, or a table with indexes that use data compression. This reduces the required log rate. This technique does increase CPU utilization and is only applicable to data sets that benefit from clustered columnstore indexes or data compression.

Tárolóhely szabályozása

A Prémium és üzletileg kritikus szolgáltatási szinteken az ügyféladatokat, köztük az adatfájlokat, a tranzakciós naplófájlokat és tempdb a fájlokat az adatbázist vagy rugalmas készletet üzemeltető gép helyi SSD-tárolójában tárolja a rendszer. A helyi SSD-tároló magas IOPS- és átviteli sebességet, valamint alacsony I/O-késést biztosít. Az ügyféladatok mellett az operációs rendszer, a felügyeleti szoftverek, a monitorozási adatok és naplók, valamint a rendszer működéséhez szükséges egyéb fájlok helyi tárolót is használnak.

A helyi tároló mérete véges, és a hardver képességeitől függ, amely meghatározza a maximális helyi tárterületkorlátot , vagy a helyi tárolót, amelyet félretesznek az ügyféladatokhoz. Ez a korlát úgy van beállítva, hogy maximalizálja az ügyfelek adattárolását, miközben biztonságos és megbízható rendszerműveletet biztosít. Az egyes szolgáltatási célok maximális helyi tárolási értékének megkereséséhez tekintse meg az önálló adatbázisok és rugalmas készletek erőforráskorlátokkal kapcsolatos dokumentációját.

Ezt az értéket és az adott adatbázis vagy rugalmas készlet által jelenleg használt helyi tároló mennyiségét is megtalálhatja az alábbi lekérdezéssel:

SELECT server_name, database_name, slo_name, user_data_directory_space_quota_mb, user_data_directory_space_usage_mb
FROM sys.dm_user_db_resource_governance
WHERE database_id = DB_ID();

Column	Leírás
server_name	Logikai kiszolgáló neve
database_name	Database name
slo_name	Szolgáltatás célkitűzésének neve, beleértve a hardvergenerálást is
user_data_directory_space_quota_mb	Maximális helyi tárterület MB-ban
user_data_directory_space_usage_mb	Az adatfájlok, tranzakciós naplófájlok és tempdb fájlok aktuális helyi tárolási felhasználása MB-ban. Öt percenként frissítve.

Ezt a lekérdezést nem az adatbázisban, hanem master a felhasználói adatbázisban kell végrehajtani. Rugalmas készletek esetén a lekérdezés a készlet bármely adatbázisában végrehajtható. A jelentett értékek a teljes készletre vonatkoznak.

Fontos

A prémium és üzletileg kritikus szolgáltatási szinteken, ha a számítási feladat adatfájlok, tranzakciónapló-fájlok és tempdb fájlok együttes helyi tárolási felhasználását próbálja növelni a maximális helyi tárterület-korláton túl, a rendszer nem szabad területet használ. Ez akkor is megtörténik, ha az adatbázisfájlban használt terület nem éri el a fájl maximális méretét.

A helyi SSD-tárolót a prémium szinten kívüli szolgáltatási szinteken lévő adatbázisok és az adatbázishoz és a tempdb rugalmas skálázású RBPEX-gyorsítótárhoz tartozó üzletileg kritikus is használják. Az adatbázisok létrehozása, törlése és méretének növelése vagy csökkentése során a gépeken a teljes helyi tárterület-használat idővel ingadozik. Ha a rendszer azt észleli, hogy a számítógépen rendelkezésre álló helyi tároló alacsony, és egy adatbázis vagy egy rugalmas készlet ki van téve a szabad terület kifutásának, áthelyezi az adatbázist vagy a rugalmas készletet egy másik gépre, amelyen elegendő helyi tároló áll rendelkezésre.

Ez az áthelyezés online módon történik, hasonlóan az adatbázis-skálázási művelethez, és hasonló hatással van, beleértve a művelet végén egy rövid (másodperces) feladatátvételt is. Ez a feladatátvétel megszakítja a nyitott kapcsolatokat, és visszaállítja a tranzakciókat, ami hatással lehet az adatbázist használó alkalmazásokra.

Mivel a rendszer minden adatot átmásol a különböző gépek helyi tárolóköteteibe, a prémium szintű és üzletileg kritikus szolgáltatási szinteken lévő nagyobb adatbázisok áthelyezése jelentős időt igényelhet. Ezalatt az idő alatt, ha egy adatbázis vagy egy rugalmas készlet vagy az adatbázis gyorsan növeli a tempdb helyi területfelhasználást, megnő a szabad terület elfogyásának kockázata. A rendszer kiegyensúlyozott módon kezdeményezi az adatbázisok áthelyezését, hogy minimalizálja a felesleges feladatátvételeket.

tempdb Méretű

Az Azure SQL Database méretkorlátjai tempdb a vásárlási és üzembehelyezési modelltől függenek.

További információkért tekintse át tempdb a méretkorlátokat a következőhöz:

• virtuális mag vásárlási modell: önálló adatbázisok, készletezett adatbázisok
• DTU vásárlási modell: önálló adatbázisok, készletezett adatbázisok.

Korábban elérhető hardver

Ez a szakasz részletesen ismerteti a korábban elérhető hardvereket.

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

Az Azure Resource Graph Explorerrel azonosíthatja az összes Olyan Azure SQL Database-erőforrást, amely jelenleg Gen4 hardvert használ, vagy ellenőrizheti az erőforrások által egy adott logikai kiszolgálóhoz használt hardvert az Azure Portalon.

Az Azure Resource Graph Explorerben az eredmények megtekintéséhez legalább read az Azure-objektumra vagy objektumcsoportra vonatkozó engedélyekkel kell rendelkeznie.

Ha a Resource Graph Explorerrel szeretné azonosítani a Gen4-hardvert még használó Azure SQL-erőforrásokat, kövesse az alábbi lépéseket:

1. Nyissa meg az Azure Portalt.

2. Keressen rá Resource graph a keresőmezőben, és válassza ki a Resource Graph Explorer szolgáltatást a keresési eredmények közül.

3. A lekérdezési ablakban írja be a következő lekérdezést, majd válassza a Lekérdezés futtatása lehetőséget:

   resources
   | where type contains ('microsoft.sql/servers')
   | where sku['family'] == "Gen4"
   

4. Az Eredmények panel megjeleníti az Azure-ban jelenleg üzembe helyezett összes, Gen4-hardvert használó erőforrást.

   

Ha ellenőrizni szeretné, hogy az erőforrások milyen hardvert használnak egy adott logikai kiszolgálóhoz az Azure-ban, kövesse az alábbi lépéseket:

1. Nyissa meg az Azure Portalt.
2. Keressen rá SQL servers a keresőmezőben, és válassza ki az SQL-kiszolgálókat a keresési eredmények közül az SQL-kiszolgálók lap megnyitásához és a kiválasztott előfizetés(ek) összes kiszolgálójának megtekintéséhez.
3. Válassza ki a megfelelő kiszolgálót a kiszolgáló Áttekintés lapjának megnyitásához.
4. Görgessen le a rendelkezésre álló erőforrásokhoz, és ellenőrizze a Tarifacsomag oszlopot a gen4 hardvert használó erőforrásokhoz.

Ha az erőforrásokat standard sorozatú hardverre szeretné migrálni, tekintse át a Hardver módosítása című cikket.

További lépések

• Az Általános Azure-korlátokról az Azure-előfizetések és -szolgáltatások korlátairól, kvótáiról és korlátairól olvashat.
• A DTU-kkal és az eDTU-kkal kapcsolatos információkért lásd: DTU-k és eDTU-k.
• A méretkorlátokról tempdb további információt az önálló virtuálismag-adatbázisok, a készletezett virtuálismag-adatbázisok, az önálló DTU-adatbázisok és a készletezett DTU-adatbázisok című témakörben talál.