SQL Hiperskálázás teljesítményének hibaelhárítása és diagnosztikai eszközök

A következőkre vonatkozik:Azure SQL Database

A rugalmas skálázású adatbázisok teljesítményproblémáinak elhárításához az általános SQL-teljesítményhangolási módszerek a teljesítményvizsgálat kiindulópontja. Tekintettel azonban a Hyperscale elosztott architektúrájára, érdemes megfontolni további diagnosztikai adatok figyelembevételét. Ez a cikk a Hyperscale-specifikus diagnosztikai adatokat ismerteti.

Csökkentett naplózási késleltetések

Az Azure SQL Database minden adatbázisa és rugalmas készlete a naplólétrehozási sebességet naplók sebességszabályozásikeresztül kezeli. A naplósebesség korlátja a primary_max_log_ratesys.dm_user_db_resource_governance oszlopában jelenik meg.

Időnként csökkenteni kell az elsődleges számítási replika naplólétrehozási sebességét a helyreállíthatósági szolgáltatásiszint-szerződések (SLA-k) fenntartása érdekében. Ez például akkor fordulhat elő, ha egy lapkiszolgáló vagy egy másik számítási replika jelentősen lemarad az új naplórekordok naplószolgáltatás általi feldolgozásában. Ha nem rendelkeznek rugalmas skálázású összetevőkkel, a naplók sebességszabályozási mechanizmusa lehetővé teszi, hogy a naplógenerálás sebessége adatbázisonként elérje a 150 MiB/s-t a prémium sorozatú és prémium sorozatú memóriaoptimalizált hardverekhez. Standard sorozatú hardverek esetén a maximális naplósebesség adatbázisonként 100 MiB/s. Rugalmas készletek esetén a maximális naplózási sebesség készletenként 150 MiB/s a prémium sorozatú és prémium sorozatú memóriaoptimalizált hardverek esetében, valamint készletenként 125 MiB/s a többi hardver esetében.

A következő várakozási típusok jelennek meg a sys.dm_os_wait_stats a naplósebesség csökkentésekor:

Várakozás típusa	Ok
`RBIO_RG_STORAGE`	Késleltetett naplófogyasztás egy oldalkiszolgáló által
`RBIO_RG_DESTAGE`	Késleltetett naplófogyasztás a hosszú távú naplótárolás által
`RBIO_RG_REPLICA`	Egy másodlagos HA-replika vagy egy elnevezett replika esetén késleltetett naplófogyasztás
`RBIO_RG_GEOREPLICA`	Késleltetett naplófogyasztás geográfiai másodlagos másolattal
`RBIO_RG_DESTAGE`	A naplószolgáltatás késleltetett naplófogyasztása
`RBIO_RG_LOCALDESTAGE`	A naplószolgáltatás késleltetett naplófogyasztása
`RBIO_RG_STORAGE_CHECKPOINT`	Lassú adatbázis-ellenőrzőpont miatt késleltetett naplóhasználat egy lapkiszolgálón
`RBIO_RG_MIGRATION_TARGET`	A nem rugalmas skálázású adatbázis késleltetett naplóhasználata a fordított migrálás során

A sys.dm_hs_database_log_rate() dinamikus felügyeleti függvény (DMF) további részleteket tartalmaz, amelyek segítenek megérteni a naplók sebességének csökkentését, ha vannak ilyenek. Megtudhatja például, hogy melyik másodlagos replika áll a naplórekordok alkalmazása mögött, és hogy mekkora a még nem alkalmazott tranzakciónapló teljes mérete.

Lapkiszolgáló olvas.

A számítási replikák nem gyorsítótárazják az adatbázis teljes másolatát helyileg. A számítási replika helyi adatait a rendszer a pufferkészletben (a memóriában) és a helyi rugalmas pufferkészlet-bővítményben (RBPEX) tárolja, amely a leggyakrabban használt adatlapok egy részét tartalmazza. Ez a helyi SSD-gyorsítótár a számítási méret arányában van méretezve. Ezzel szemben minden lapkiszolgáló teljes SSD-gyorsítótárral rendelkezik az adatbázis azon részének, amelyet fenntart.

Ha olvasási IO-t adnak ki egy számítási replikán, és az adatok nem léteznek a pufferkészletben vagy a helyi SSD-gyorsítótárban, akkor a rendszer a kért Napló Sorszám (LSN) szerinti lapot a megfelelő lapkiszolgálóról kéri le. A lapkiszolgálókról érkező olvasások távoliak, és lassabbak, mint a helyi SSD-gyorsítótárból származó olvasások. Az I/O-kkal kapcsolatos teljesítményproblémák elhárításakor meg kell tudnunk állapítani, hogy hány I/O történt a viszonylag lassabb oldalkiszolgálói olvasásokon keresztül.

Számos dinamikus felügyelt nézet (DMV) és kiterjesztett esemény oszlopokkal és mezőkkel rendelkezik, amelyek meghatározzák az oldalkiszolgálóról származó távoli olvasások számát, amely összehasonlítható az összes olvasással. A Lekérdezéstár a lapkiszolgáló olvasásait is rögzíti a lekérdezési futtatókörnyezet statisztikáiban.

A jelentésoldal kiszolgáló által olvasott oszlopok elérhetők a végrehajtási DMV-k és a katalógus nézetek között.
A lapkiszolgáló olvasási mezői a következő kiterjesztett eseményekben találhatók:
- sql_statement_completed
- sp_statement_completed
- sql_batch_completed
- rpc_completed
- scan_stopped
- query_store_begin_persist_runtime_stat
- query_store_execution_runtime_info
ActualPageServerReads / ActualPageServerReadAheads attribútumok szerepelnek a lekérdezési terv XML-fájljában a futtatókörnyezeti statisztikákat tartalmazó csomagok esetében. Például:
```
<RunTimeCountersPerThread Thread="8" ActualRows="90466461" [...] ActualPageServerReads="0" ActualPageServerReadAheads="5687297" ActualLobPageServerReads="0" ActualLobPageServerReadAheads="0" />
```
Borravaló

Ezeknek az attribútumoknak a lekérdezésterv tulajdonságai ablakban való megtekintéséhez az SSMS 18.3 vagy újabb verziójára van szükség.

Virtuális fájlstatisztikák és IO-nyilvántartás

Az Azure SQL Database-ben a sys.dm_io_virtual_file_stats() DMF az egyik módja annak, hogy figyelemmel kísérjük az adatbázis I/O-statisztikáit, például az IOPS-ot, az átviteli sebességet és a késleltetést. A Hyperscale I/O jellemzői a elosztott architektúramiatt eltérőek. Ebben a szakaszban az I/O olvasására és írására összpontosítunk, ahogyan az ebben a DMF-ben látható.

Hyperscale esetén a vonatkozó adatok sys.dm_io_virtual_file_stats() a következők:

Azok a sorok, ahol az database_id érték megegyezik a DB_ID függvény által visszaadott értékkel, és ahol az file_id érték nem 2, lapkiszolgálóknak felelnek meg. Általában minden sor egy lapkiszolgálónak felel meg. Nagyobb fájlok esetén azonban több lapkiszolgálót is használ a rendszer.
- A 2-vel rendelkező file_id sor a tranzakciónaplónak felel meg.
Azok a sorok, ahol az database_id oszlop értéke 0, megfelelnek a számítási replika helyi SSD-gyorsítótárának.

Helyi SSD-gyorsítótár használata

Mivel a helyi SSD-gyorsítótár ugyanazon a számítási replikán található, ahol az adatbázismotor lekérdezéseket dolgoz fel, az I/O a gyorsítótáron gyorsabb, mint az I/O a lapkiszolgálókon. Rugalmas skálázású adatbázisokban vagy rugalmas készletekben sys.dm_io_virtual_file_stats() speciális sorok jelentik a helyi SSD-gyorsítótár I/O-statisztikáit. Ezek a sorok database_id oszlopára 0 értéket tartalmaznak. Az alábbi lekérdezés például a helyi SSD-gyorsítótár I/O-statisztikáit adja vissza az adatbázis indítása óta.

SELECT *
FROM sys.dm_io_virtual_file_stats(0, NULL);

A helyi SSD-gyorsítótárfájlokból származó összesített olvasások és az összes többi adatfájl összesített olvasásainak aránya a helyi SSD-gyorsítótár találati aránya. Ezt a metrikát a RBPEX cache hit ratio DMV-ben elérhető RBPEX cache hit ratio base és teljesítményszámlálók biztosítják.

Adatolvasások

Ha az olvasásokat az adatbázismotor egy számítási replikán adja ki, azokat vagy a helyi SSD-gyorsítótár, vagy a lapkiszolgálók, vagy a kettő kombinációja szolgáltatja, ha több oldalt olvas.
Ha a számítási replika bizonyos lapokat olvas be egy adott adatfájlból (például az 1-et tartalmazó file_id fájlból), ha ezek az adatok csak a helyi SSD-gyorsítótárban találhatók, az olvasáshoz szükséges összes I/O a helyi SSD-gyorsítótár fájljain lesz elszámolva, ahol database_id 0. Ha az adatok egy része a helyi SSD-gyorsítótárban található, és egy része lapkiszolgálókon található, akkor az IO részben a helyi SSD-gyorsítótárfájlok felé, részben pedig a lapkiszolgálóknak megfelelő adatfájlok felé van elszámolva.
Ha egy számítási replika egy adott LSN-nél kér egy lapot a lapkiszolgálótól, és a lapkiszolgáló még nem érte el a kért LSN-t, a számítási replikán lévő olvasás megvárja, amíg a lapkiszolgáló el nem éri azt, mielőtt a lap visszaadásra kerül. Ha a számítási replikán lévő lapkiszolgálóról olvas, megjelenik egy PAGEIOLATCH_* várakozási típus, ha az IO-ra vár. Rugalmas skálázás esetén ez a várakozási idő magában foglalja a lapkiszolgáló kért lapjának a szükséges LSN-be való felzárkózásához szükséges időt, valamint a lapnak a lapkiszolgálóról a számítási replikára való átviteléhez szükséges időt.
A nagy olvasások, például az előreolvasások gyakran pontgyűjtő olvasásokhasználatával végezhetők el. Ez lehetővé teszi akár 4 MB-os olvasást egyetlen olvasási IO-ként. Ha azonban az éppen beolvasott adatok a helyi SSD-gyorsítótárban vannak, ezek az olvasások több különálló 8 KB-os olvasásként vannak elszámolva, mivel a pufferkészlet és a helyi SSD-gyorsítótár mindig 8 KB-os oldalakat használ. Ennek eredményeképpen a helyi SSD-gyorsítótárban látható olvasási I/O-k száma nagyobb lehet, mint a motor által végrehajtott I/O-k tényleges száma.

Adatírás

Az elsődleges számítási replika nem ír közvetlenül a lapkiszolgálókhoz. Ehelyett a naplószolgáltatás naplórekordjai a megfelelő lapkiszolgálókon lesznek újra lejátszva.
A számítási replikán végzett írások túlnyomórészt a helyi SSD-gyorsítótárba íródnak (database_id 0). A 8 KB-nál nagyobb írások, vagyis a gyűjtési-írásihasználatával végzett írások esetében minden írási művelet több 8 KB-os egyéni írásra lesz lefordítva a helyi SSD-gyorsítótárba, mivel a pufferkészlet és a helyi SSD-gyorsítótár mindig 8 KB-os oldalakat használ. Ennek eredményeképpen a helyi SSD-gyorsítótárban látható írási I/O-k száma nagyobb lehet, mint a motor által végrehajtott I/O-k tényleges száma.
A lapkiszolgálóknak megfelelő, nem database_id 0 típusú adatfájlok írást is végezhetnek. Rugalmas skálázás esetén ezek az írások szimulálva vannak, mivel a számítási replikák soha nem írnak közvetlenül lapkiszolgálókra. Az I/O-statisztikák a számítási replikán való előfordulásukkor lesznek elszámolva. A 0-n kívüli database_id adatfájlok számítási replikáján látható írási IOPS, átviteli sebesség és késés nem tükrözi a lapkiszolgálókon előforduló írások tényleges I/O-statisztikáit.

Napló bejegyzések

Az elsődleges számítási replikán a naplóírások 2 alatt sys.dm_io_virtual_file_stats() vannak elszámolvafile_id.
A rendelkezésre állási csoportoktól eltérően, ha egy tranzakció véglegesítése az elsődleges számítási replikán történik, a naplórekordok nem lesznek megerősítve a másodlagos replikán. Hyperscale esetében a napló megszilárdul a naplószolgáltatásban, és aszinkron módon alkalmazzák a másodlagos replikákra. Mivel a naplóírások valójában nem másodlagos replikákon történnek, a napló I/O műveletek sys.dm_io_virtual_file_stats() másodlagos replikákon való számítását nem szabad tranzakciónapló I/O-statisztikaként használni.

Adat I/O az erőforrás-kihasználtsági statisztikákban

A nem rugalmas skálázású adatbázisokban az összesített olvasási és írási IOPS a erőforrás-gazdálkodás adat I/O-korlátjához viszonyítva a sys.dm_db_resource_stats és sys.resource_stats nézetekben van jelentve, az avg_data_io_percent oszlopban. A rugalmas készletek megfelelő DMV-jei sys.dm_elastic_pool_resource_stats és sys.elastic_pool_resource_stats. Ugyanazok az értékek jelennek meg, mint a adat IO százalékos mértéke Azure Monitor-metrikák adatbázisoknál és rugalmas készleteknél.

A rugalmas skálázású adatbázisokban ezek az oszlopok és metrikák az adatok I/O-kihasználtságáról számolnak be a csak számítási replikán lévő helyi SSD-tárterület korlátaihoz képest, beleértve az I/O-t a helyi SSD-gyorsítótár és az tempdb adatbázis számára. Az oszlop 100% értéke azt jelzi, hogy az erőforrás-szabályozás korlátozza a helyi tároló IOPS-t. Ha ez egy teljesítményproblémával van összefüggésben, hangolja a számítási feladatot kevesebb I/O-érték létrehozására, vagy növelje a számítási méretet az erőforrás-szabályozási Maximális adatmennyiség IOPSkorlátnövelése érdekében. A helyi SSD-gyorsítótár olvasási és írási erőforrás-szabályozásához a rendszer az adatbázismotor által esetleg kibocsátott nagyobb IOS-k helyett az egyes 8 KB-os IOS-eket számolja.

A lapkiszolgálókkal szemben végzett adat-I/O műveletek nincsenek jelenítve az erőforrás-kihasználtsági nézetekben vagy az Azure Monitor metrikái között, hanem a korábban ismertetett módon jelentkeznek sys.dm_io_virtual_file_stats().

Visszajelzés

Hasznosnak találta ezt az oldalt?

Last updated on 2025-11-05