Erőforrás-kezelés sűrű rugalmas készletekben

A következőre vonatkozik: Azure SQL Database

Az Azure SQL Database rugalmas készletei költséghatékony megoldást jelent számos különböző erőforrás-használatú adatbázis kezelésére. A rugalmas készlet összes adatbázisa azonos erőforrás-kiosztással rendelkezik, például PROCESSZOR, memória, feldolgozószálak, tárterület, azzal a feltételezéssel, tempdbhogy a készletben lévő adatbázisoknak csak egy részhalmaza fog számítási erőforrásokat használni. Ez a feltételezés lehetővé teszi, hogy a rugalmas készletek költséghatékonyak legyenek. Ahelyett, hogy minden egyes adatbázisnak szüksége lenne az összes erőforrásra, az ügyfelek sokkal kisebb erőforráskészletért fizetnek, amelyek a készlet összes adatbázisa között megosztva lesznek.

Erőforrások szabályozása

Az erőforrás-megosztás megköveteli, hogy a rendszer gondosan szabályozza az erőforrás-használatot a "zajos szomszéd" hatás minimalizálása érdekében, ahol a nagy erőforrás-felhasználású adatbázisok hatással vannak az ugyanazon rugalmas készletben lévő többi adatbázisra. Az Azure SQL Database az erőforrás-szabályozás implementálásával valósítja meg ezeket a célokat. Ugyanakkor a rendszernek elegendő erőforrást kell biztosítania olyan funkciókhoz, mint a magas rendelkezésre állás és a vészhelyreállítás (HADR), a biztonsági mentés és visszaállítás, a monitorozás, a lekérdezéstár, az automatikus hangolás stb. megbízható működéshez.

A rugalmas készletek elsődleges tervezési célja a költséghatékonyság. Emiatt a rendszer szándékosan lehetővé teszi az ügyfelek számára, hogy sűrű készleteket hozzanak létre, azaz olyan készleteket, amelyek száma megközelíti vagy maximálisan engedélyezett, de a számítási erőforrások mérsékelt lefoglalásával. Ugyanezen okból a rendszer nem foglalja le az összes potenciálisan szükséges erőforrást a belső folyamatokhoz, hanem lehetővé teszi az erőforrások megosztását a belső folyamatok és a felhasználói számítási feladatok között.

Ez a megközelítés lehetővé teszi az ügyfelek számára, hogy sűrű rugalmas készleteket használjanak a megfelelő teljesítmény és a jelentős költségmegtakarítás érdekében. Ha azonban a sűrű készletben lévő számos adatbázis számítási feladatai kellően intenzívek, az erőforrás-versengés jelentős lesz. Az erőforrás-versengés csökkenti a felhasználói számítási feladatok teljesítményét, és negatív hatással lehet a belső folyamatokra.

Fontos

A sok aktív adatbázissal rendelkező sűrű készletekben nem lehetséges a készletben lévő adatbázisok számának növelése a rugalmas DTU- és virtuális magkészletek esetében dokumentált maximális értékig.

A sűrű készletekbe helyezhető adatbázisok száma erőforrás-versengés és teljesítményproblémák nélkül az egyidejűleg aktív adatbázisok számától és az egyes adatbázisok felhasználói számítási feladatai által nyújtott erőforrás-felhasználástól függ. Ez a szám idővel változhat a felhasználói számítási feladatok változásakor.

Ezenkívül ha a minimális virtuális magok adatbázisonként, vagy az adatbázisonkénti minimális DTU-k értéke 0-nál nagyobb, a készletben lévő adatbázisok maximális száma implicit módon korlátozott lesz. További információkért tekintse meg a készletezett virtuálismag-adatbázisok adatbázistulajdonságait és a készletezett DTU-adatbázisok adatbázistulajdonságait.

Ha az erőforrás-versengés sűrűn csomagolt készletben történik, az ügyfelek az alábbi műveletek közül választhatnak a probléma enyhítésére:

• A lekérdezési számítási feladatok hangolásával csökkentheti az erőforrás-felhasználást, vagy eloszthatja az erőforrás-felhasználást több adatbázis között az idő függvényében.
• Csökkentheti a készlet sűrűségét úgy, hogy egyes adatbázisokat áthelyez egy másik készletbe, vagy önálló adatbázisokat hoz létre.
• Skálázza fel vertikálisan a készletet, hogy több erőforrása legyen.

Az utolsó két művelet végrehajtásával kapcsolatos javaslatokért tekintse meg a cikk későbbi, működési javaslatait . Az erőforrás-versengés csökkentése mind a felhasználói számítási feladatok, mind a belső folyamatok számára előnyös, és lehetővé teszi, hogy a rendszer megbízhatóan fenntartsa a várt szolgáltatási szintet.

Erőforrás-felhasználás monitorozása

Az erőforrás-versengés miatti teljesítménycsökkenés elkerülése érdekében a sűrű rugalmas készleteket használó ügyfeleknek proaktívan figyelniük kell az erőforrás-felhasználást, és időben kell cselekedniük, ha az erőforrás-versengés növekedése hatással van a számítási feladatokra. A folyamatos figyelés azért fontos, mert a készlet erőforrás-kihasználtsága idővel megváltozik a felhasználói számítási feladatok, az adatmennyiségek és az elosztás változásai, a készlet sűrűségének változása és az Azure SQL Database szolgáltatás változásai miatt.

Az Azure SQL Database számos olyan metrikát biztosít, amelyek relevánsak az ilyen típusú monitorozáshoz. Az egyes metrikák javasolt átlagértékének túllépése a készletben lévő erőforrás-versengést jelzi, és a korábban említett műveletek egyikével kell foglalkozni.

Ha riasztást szeretne küldeni, ha a készlet erőforrás-kihasználtsága (CPU, adat IO, napló IO, feldolgozók stb.) túllépi a küszöbértéket, érdemes lehet riasztásokat létrehozni az Azure Portalon vagy az Add-AzMetricAlertRulev2 PowerShell-parancsmagon keresztül. A rugalmas készletek monitorozása során érdemes lehet riasztásokat is létrehozni a készletben lévő egyes adatbázisokhoz, ha szükséges a forgatókönyvben. A rugalmas készletek monitorozásának mintaforgatókönyve: Az Azure SQL Database teljesítményének monitorozása és kezelése több-bérlős SaaS-alkalmazásokban.

Metrika neve	Leírás	Ajánlott átlagérték
avg_instance_cpu_percent	A rugalmas készlethez társított SQL-folyamat CPU-kihasználtsága az alapul szolgáló operációs rendszer által mért módon. Minden adatbázisban elérhető sys.dm_db_resource_stats nézetben és az adatbázis sys.elastic_pool_resource_stats nézetébenmaster. Ez a metrikát az Azure Monitor is kibocsátja, ahol elneveztéksql_instance_cpu_percent, és megtekinthető az Azure Portalon. Ez az érték ugyanaz a rugalmas készletben lévő összes adatbázis esetében.	70% alatt. A 90%-ig esetenkénti rövid kiugrás elfogadható lehet.
max_worker_percent	Feldolgozói szál kihasználtsága. A készlet minden adatbázisához, valamint magához a készlethez is meg van adva. Az adatbázis szintjén és a készlet szintjén különböző korlátok vonatkoznak a feldolgozói szálak számára, ezért ajánlott mindkét szinten figyelni ezt a metrikát. Minden adatbázisban elérhető sys.dm_db_resource_stats nézetben és az adatbázis sys.elastic_pool_resource_stats nézetébenmaster. Ez a metrikát az Azure Monitor is kibocsátja, ahol elneveztékworkers_percent, és megtekinthető az Azure Portalon.	80% alatt. A 100%-ig felugró csúcsok a csatlakozási kísérletek és a lekérdezések sikertelenségéhez vezetnek.
avg_data_io_percent	IOPS-kihasználtság a fizikai IO olvasásához és írásához. A készlet minden adatbázisához, valamint magához a készlethez is meg van adva. Az adatbázis szintjén és a készlet szintjén az IOPS számának különböző korlátai vannak, ezért ajánlott mindkét szinten figyelni ezt a metrikát. Minden adatbázisban elérhető sys.dm_db_resource_stats nézetben és az adatbázis sys.elastic_pool_resource_stats nézetébenmaster. Ez a metrikát az Azure Monitor is kibocsátja, ahol elneveztékphysical_data_read_percent, és megtekinthető az Azure Portalon.	80% alatt. A 100%-ig esetenkénti rövid kiugrás elfogadható lehet.
avg_log_write_percent	A tranzakciónapló írási I/O átviteli sebességének kihasználtsága. A készlet minden adatbázisához, valamint magához a készlethez is meg van adva. A napló átviteli sebességének különböző korlátai vannak az adatbázis szintjén és a készlet szintjén, ezért ajánlott mindkét szinten figyelni ezt a metrikát. Minden adatbázisban elérhető sys.dm_db_resource_stats nézetben és az adatbázis sys.elastic_pool_resource_stats nézetébenmaster. Ez a metrikát az Azure Monitor is kibocsátja, ahol elneveztéklog_write_percent, és megtekinthető az Azure Portalon. Ha ez a metrika megközelíti a 100%-ot, az összes adatbázis-módosítás (INSERT, UPDATE, DELETE, MERGE utasítás, SELECT ... INTO, BULK INSERT stb.) lassabb lesz.	90% alatt. A 100%-ig esetenkénti rövid kiugrás elfogadható lehet.
oom_per_second	A rugalmas készletben a memóriakihasználtság (OOM) hibáinak aránya, amely a memóriaterhelést jelzi. Sys.dm_resource_governor_resource_pools_history_ex nézetben érhető el. A metrika kiszámításához tekintse meg a példákat egy minta lekérdezéshez. További információkért tekintse meg a DTU-kat vagy rugalmas készleteket használó rugalmas készletekre vonatkozó erőforráskorlátokat virtuális magokkal, valamint az Azure SQL Database-beli memóriakihasználtság hibáinak elhárítása című témakört. Ha memóriahiány miatti hibákat tapasztal, tekintse át a sys.dm_os_out_of_memory_events dokumentációját.	0
avg_storage_percent	A rugalmas készleten belüli összes adatbázis adatai által használt teljes tárterület. Nem tartalmaz üres helyet az adatbázisfájlokban. Az adatbázis sys.elastic_pool_resource_stats nézetében master érhető el. Ez a metrikát az Azure Monitor is kibocsátja, ahol elneveztékstorage_percent, és megtekinthető az Azure Portalon.	80% alatt. Elérheti a 100%-ot az adatnövekedés nélküli készletek esetében.
avg_allocated_storage_percent	A rugalmas készleten belüli összes adatbázisban található adatbázisfájlok által használt teljes tárterület. Üres helyet tartalmaz az adatbázisfájlokban. Az adatbázis sys.elastic_pool_resource_stats nézetében master érhető el. Ez a metrikát az Azure Monitor is kibocsátja, ahol elneveztékallocated_data_storage_percent, és megtekinthető az Azure Portalon.	90% alatt. Elérheti a 100%-ot az adatnövekedés nélküli készletek esetében.
tempdb_log_used_percent	Tranzakciónapló-terület kihasználtsága az tempdb adatbázisban. Annak ellenére, hogy az egyik adatbázisban létrehozott ideiglenes objektumok nem láthatók az ugyanabban a rugalmas készletben lévő többi adatbázisban, tempdb az ugyanazon készletben lévő összes adatbázis megosztott erőforrása. A készlet egyik adatbázisából indított hosszú ideig futó vagy árva tranzakciók tempdb a tranzakciónapló nagy részét felhasználhatják, és hibákat okozhatnak az ugyanabban a készletben lévő más adatbázisok lekérdezéseiben. Sys.dm_db_log_space_usage és sys.database_files nézetekből származik. Ez a metrikát az Azure Monitor is kibocsátja, és megtekinthető az Azure Portalon. Példák a metrika aktuális értékének visszaadására szolgáló minta lekérdezésekhez.	50% alatt. Az alkalmankénti 80%-os kiugrás elfogadható.

Ezen metrikák mellett az Azure SQL Database olyan nézetet is biztosít, amely a tényleges erőforrás-szabályozási korlátokat adja vissza, valamint további nézeteket, amelyek erőforrás-kihasználtsági statisztikákat ad vissza az erőforráskészlet szintjén és a számítási feladatcsoport szintjén.

Nézet neve	Leírás
sys.dm_user_db_resource_governance	Az aktuális adatbázis vagy rugalmas készlet erőforrás-szabályozási mechanizmusai által használt tényleges konfigurációs és kapacitásbeállításokat adja vissza.
sys.dm_resource_governor_resource_pools	Az erőforráskészlet aktuális állapotára, az erőforráskészletek aktuális konfigurációjára és az összesített erőforráskészlet-statisztikákra vonatkozó információkat adja vissza.
sys.dm_resource_governor_workload_groups	A számítási feladatcsoport összesített statisztikáit és a számítási feladatcsoport aktuális konfigurációját adja vissza. Ez a nézet az oszlop sys.dm_resource_governor_resource_pools is csatlakoztatható az pool_id erőforráskészlet adatainak lekéréséhez.
sys.dm_resource_governor_resource_pools_history_ex	A legutóbbi előzmények erőforráskészlet-kihasználtsági statisztikáit adja vissza az elérhető pillanatképek száma alapján. Minden sor egy időintervallumot jelöl. Az intervallum időtartamát az duration_ms oszlop tartalmazza. Az delta_ oszlopok az intervallum alatt az egyes statisztikákban bekövetkező változást adják vissza.
sys.dm_resource_governor_workload_groups_history_ex	A számítási feladatcsoport legutóbbi előzményeinek kihasználtsági statisztikáit adja vissza az elérhető pillanatképek száma alapján. Minden sor egy időintervallumot jelöl. Az intervallum időtartamát az duration_ms oszlop tartalmazza. Az delta_ oszlopok az intervallum alatt az egyes statisztikákban bekövetkező változást adják vissza.

Tipp

Ha ezeket és más dinamikus felügyeleti nézeteket nem kiszolgálóadminisztrátor használatával szeretné lekérdezni, vegye fel ezt az egyszerű nevet a ##MS_ServerStateReader##kiszolgálói szerepkörbe.

Ezek a nézetek az erőforrás-kihasználtság monitorozására és az erőforrás-versengés közel valós idejű hibaelhárítására használhatók. 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 feladatcsoportba vannak besorolva, ahol N az adatbázis-azonosító értéke áll.

Az aktuális erőforrás-kihasználtság monitorozása mellett a sűrű készleteket használó ügyfelek külön adattárban is megőrizhetik az előzményerőforrás-kihasználtsági adatokat. Ezek az adatok felhasználhatók prediktív elemzésekben az erőforrás-kihasználtság proaktív kezelésére az előzmény- és szezonális trendek alapján.

Működési javaslatok

Hagyjon elegendő erőforrás-fejszobát. Ha erőforrás-versengés és teljesítménycsökkenés történik, a kockázatcsökkentés magában foglalhat bizonyos adatbázisokat az érintett rugalmas készletből való áthelyezésével vagy a készlet felskálázásával, amint azt korábban említettük. Ezek a műveletek azonban további számítási erőforrásokat igényelnek. A prémium és üzleti szempontból kritikus készletek esetében ezek a műveletek megkövetelik az áthelyezett adatbázisok összes adatának, illetve a rugalmas készlet összes adatbázisának átvitelét, ha a készlet felskálázva van. Az adatátvitel hosszú ideig futó és erőforrásigényes művelet. Ha a készlet már nagy erőforrás-nyomás alatt van, maga az enyhítő művelet még tovább rontja a teljesítményt. Szélsőséges esetekben előfordulhat, hogy az erőforrás-versengés nem oldható meg adatbázis-áthelyezéssel vagy készletméretezéssel, mert a szükséges erőforrások nem érhetők el. Ebben az esetben az érintett rugalmas készlet lekérdezési számítási feladatainak ideiglenes csökkentése lehet az egyetlen megoldás.

A sűrű készleteket használó ügyfeleknek szorosan figyelniük kell az erőforrás-kihasználtsági trendeket a korábban leírtak szerint, és enyhíteni kell a műveletet, miközben a metrikák az ajánlott tartományokon belül maradnak, és továbbra is elegendő erőforrás található a rugalmas készletben.

Az erőforrás-kihasználtság több tényezőtől függ, amelyek idővel változnak az egyes adatbázisok és az egyes rugalmas készletek esetében. Az optimális ár/teljesítmény arány elérése sűrű készletekben folyamatos monitorozást és kiegyensúlyozást igényel, vagyis az adatbázisokat a kihasználtabb készletekről a kevésbé kihasznált készletekre kell áthelyezni, és szükség szerint új készleteket kell létrehozni a megnövekedett számítási feladatokhoz.

Megjegyzés:

A rugalmas DTU-készletek esetében az eDTU-metrika a készlet szintjén nem max vagy az egyes adatbázisok kihasználtságának összege. hanem a különböző készletszintű metrikák használatából származik. A készletszintű erőforráskorlátok magasabbak lehetnek az adatbázisszintű korlátoknál, így egy-egy adatbázis akkor is elérhet egy adott erőforráskorlátot (CPU, adat-I/O, napló-I/O stb.), ha a készlet eDTU-jelentései nem jelzik, hogy bármilyen korlátot elért volna.

Ne helyezze át a "gyakori elérésű" adatbázisokat. Ha a készlet szintjén az erőforrás-versengést elsősorban kevés, magas kihasználtságú adatbázis okozza, csábító lehet ezeket az adatbázisokat egy kevésbé kihasznált készletbe áthelyezni, vagy önálló adatbázissá tenni őket. Ez azonban nem ajánlott, amíg egy adatbázis továbbra is magas kihasználtságú marad, mivel az áthelyezési művelet tovább rontja a teljesítményt mind az áthelyezett adatbázis, mind a teljes készlet esetében. Ehelyett várjon, amíg a magas kihasználtság megszűnik, vagy helyezzen át kevésbé kihasznált adatbázisokat, hogy enyhítse az erőforrás-terhelést a készlet szintjén. A nagyon alacsony kihasználtságú adatbázisok áthelyezése azonban ebben az esetben nem nyújt semmilyen előnyt, mivel a készlet szintjén nem csökkenti jelentősen az erőforrás-kihasználtságot.

Hozzon létre új adatbázisokat egy "karantén" készletben. Olyan esetekben, amikor gyakran jönnek létre új adatbázisok, például a bérlőnkénti modellt használó alkalmazások, fennáll a veszélye annak, hogy egy meglévő rugalmas készletbe helyezett új adatbázis váratlanul jelentős erőforrásokat fog használni, és hatással lesz a készlet többi adatbázisára és belső folyamatára. A kockázat csökkentése érdekében hozzon létre egy külön "karantén" készletet az erőforrások bőséges lefoglalásával. Ezt a készletet olyan új adatbázisokhoz használhatja, amely még nem ismert erőforrás-használati mintákkal rendelkezik. Ha egy adatbázis egy üzleti ciklusban (például egy hét vagy egy hónap) ebben a készletben maradt, és ismert az erőforrás-felhasználás, áthelyezhető egy olyan készletbe, amely elegendő kapacitással rendelkezik a további erőforrás-használathoz.

Figyelje a felhasznált és a lefoglalt területet is. Ha a lefoglalt készletterület (a készletben lévő összes adatbázisfájl teljes mérete) eléri a készlet maximális méretét, szabad területhiba léphet fel. Ha a lefoglalt terület trendjei magasak, és a maximális készletméret elérése érdekében jó úton haladnak, a kockázatcsökkentési lehetőségek a következők:

• Egyes adatbázisok áthelyezése a készletből a teljes lefoglalt terület csökkentése érdekében
• Adatbázisfájlok zsugorítása a fájlok üres lefoglalt helyének csökkentése érdekében
• A készlet vertikális felskálázása szolgáltatási célkitűzésre nagyobb maximális készletmérettel

Ha a készlet kihasználtsága (a készlet összes adatbázisában lévő adatok teljes mérete, a fájlokban lévő üres hely ki nem számítva) trendek magasak, és a készlet maximális méretének elérése érdekében jó úton halad, a kockázatcsökkentési lehetőségek a következők:

• Egyes adatbázisok áthelyezése a készletből a teljes kihasználtság csökkentése érdekében
• Adatok áthelyezése (archiválása) az adatbázison kívülre, vagy a már nem szükséges adatok törlése
• Adattömörítés implementálása
• A készlet vertikális felskálázása szolgáltatási célkitűzésre nagyobb maximális készletmérettel

Kerülje a túl sűrű kiszolgálókat. Az Azure SQL Database kiszolgálónként legfeljebb 5000 adatbázist támogat . A több ezer adatbázissal rendelkező rugalmas készleteket használó ügyfelek fontolóra vehetik, hogy több rugalmas készletet helyeznek el egyetlen kiszolgálón, az adatbázisok teljes száma pedig a támogatott korlátig. A sok ezer adatbázissal rendelkező kiszolgálók azonban üzemeltetési kihívásokat jelentenek. Az olyan műveletek, amelyekhez egy kiszolgáló összes adatbázisának számbavétele szükséges, például az adatbázisok megtekintése a portálon, lassabbak lesznek. A működési hibák, például a kiszolgálószintű bejelentkezések vagy tűzfalszabályok helytelen módosítása nagyobb számú adatbázist érintenek. A kiszolgáló véletlen törlése esetén a Microsoft támogatási szolgálata segítséget fog kérni a törölt kiszolgálón lévő adatbázisok helyreállításához, és az összes érintett adatbázis esetében hosszan tartó üzemkimaradást fog okozni.

A kiszolgálónkénti adatbázisok számát a maximális támogatott számnál alacsonyabbra korlátozhatja. Sok esetben kiszolgálónként legfeljebb 1000–2000 adatbázis használata optimális. A kiszolgáló véletlen törlésének valószínűségének csökkentése érdekében helyezzen törlési zárolást a kiszolgálóra vagy annak erőforráscsoportjára.

Példák

Az adatbázis-kapacitás egyes beállításainak megtekintése

sys.dm_user_db_resource_governance A dinamikus felügyeleti nézetben megtekintheti az erőforrás-szabályozás által az aktuális adatbázisban vagy rugalmas készletben használt tényleges konfigurációs és kapacitásbeállításokat. További információ: sys.dm_user_db_resource_governance.

Futtassa ezt a lekérdezést egy rugalmas készlet bármely adatbázisában. A készlet összes adatbázisa ugyanazokat az erőforrás-szabályozási beállításokat használja.

SELECT * FROM sys.dm_user_db_resource_governance AS rg
WHERE database_id = DB_ID();

A rugalmas készlet általános erőforrás-felhasználásának monitorozása

sys.elastic_pool_resource_stats A rendszerkatalógus nézettel monitorozza a teljes készlet erőforrás-felhasználását. További információ: sys.elastic_pool_resource_stats.

Ezt a minta lekérdezést az elmúlt 10 perc megtekintéséhez a master kívánt rugalmas készletet tartalmazó logikai Azure SQL Server adatbázisában kell futtatni.

SELECT * FROM sys.elastic_pool_resource_stats AS rs
WHERE rs.start_time > DATEADD(mi, -10, SYSUTCDATETIME()) 
AND rs.elastic_pool_name = '<elastic pool name>';

Az egyes adatbázis-erőforrások felhasználásának monitorozása

sys.dm_db_resource_stats A dinamikus felügyeleti nézettel figyelheti az egyes adatbázisok erőforrás-felhasználását. További információ: sys.dm_db_resource_stats. Egy sor 15 másodpercenként létezik, még akkor is, ha nincs tevékenység. Az előzményadatok körülbelül egy óráig maradnak fenn.

Ezt a minta lekérdezést az utolsó 10 perc adatainak megtekintéséhez a kívánt adatbázisban kell futtatni.

SELECT * FROM sys.dm_db_resource_stats AS rs
WHERE rs.end_time > DATEADD(mi, -10, SYSUTCDATETIME());

A hosszabb, kisebb gyakoriságú megőrzési idő érdekében fontolja meg a következő lekérdezést sys.resource_stats, amely az master Azure SQL logikai kiszolgáló adatbázisában fut. További információ: sys.resource_stats (Azure SQL Database). Öt percenként egy sor létezik, és az előzményadatok két hétig megmaradnak.

SELECT * FROM sys.resource_stats
WHERE [database_name] = 'sample'
ORDER BY [start_time] desc;

Memóriakihasználtság monitorozása

Ez a lekérdezés kiszámítja az oom_per_second egyes erőforráskészletek metrikáit a legutóbbi előzményekhez az elérhető pillanatképek száma alapján. Ez a minta lekérdezés segít azonosítani a készlet sikertelen memóriafoglalásainak legutóbbi átlagos számát. Ez a lekérdezés egy rugalmas készlet bármely adatbázisában futtatható.

SELECT pool_id,
       name AS resource_pool_name,
       IIF(name LIKE 'SloSharedPool%' OR name LIKE 'UserPool%', 'user', 'system') AS resource_pool_type,
       SUM(CAST(delta_out_of_memory_count AS decimal))/(SUM(duration_ms)/1000.) AS oom_per_second
FROM sys.dm_resource_governor_resource_pools_history_ex
GROUP BY pool_id, name
ORDER BY pool_id;

Naplóterület kihasználtságának monitorozása tempdb

Ez a lekérdezés a metrika aktuális értékét tempdb_log_used_percent adja vissza, amely a tranzakciónapló relatív kihasználtságát mutatja a tempdb maximális megengedett mérethez képest. Ez a lekérdezés egy rugalmas készlet bármely adatbázisában futtatható.

SELECT (lsu.used_log_space_in_bytes / df.log_max_size_bytes) * 100 AS tempdb_log_space_used_percent
FROM tempdb.sys.dm_db_log_space_usage AS lsu
CROSS JOIN (
           SELECT SUM(CAST(max_size AS bigint)) * 8 * 1024. AS log_max_size_bytes
           FROM tempdb.sys.database_files
           WHERE type_desc = N'LOG'
           ) AS df
;

További lépések

• A rugalmas készletek bemutatása: Rugalmas készletek, amelyek segítségével több adatbázist kezelhet és skálázhat az Azure SQL Database-ben.
• Az erőforrás-kihasználtság csökkentése érdekében a lekérdezési számítási feladatok hangolásával kapcsolatos információkért lásd: Figyelés és finomhangolás, monitorozás és teljesítményhangolás.