SQL Server Aktivitásfigyelő: Teljes körű útmutató adatbázis-adminisztrátoroknak [2026]

1. Bevezetés

1.1 Mi az SQL Server ActivityMonitor?

SQL Server Az Aktivitásfigyelő egy beépített diagnosztikai eszköz.ostic eszköz belül SQL Server Management Studio, amely információkat jelenít meg a következőről: SQL Server folyamatok és azok hatása a szerver teljesítményére. Lehetővé teszi a nyomon követést SQL Server folyamatokat, figyelheti az erőforrás-várakozásokat, elemezheti a költséges lekérdezéseket és megfigyelheti az I/O mintákat – mindezt egyetlen felületről.

1.2 Miért érdemes használni? SQL Server ActivityMonitor?

Az Aktivitásfigyelő az első védelmi vonal a teljesítményproblémák elhárításakor. Azonnali rálátást biztosít arra, hogy mi történik a... SQL Server példányban, összetett T-SQL lekérdezések vagy harmadik féltől származó eszközök nélkül.

Az eszköz kiválóan alkalmas a gyakori problémák, például a blokkoló munkamenetek, a CPU-igényes lekérdezések, a túlzott lekérdezés-végrehajtás és az I/O szűk keresztmetszetek gyors azonosítására. Amikor a felhasználók arról számolnak be, hogy egy alkalmazás lassú vagy nem reagál, az Activity Monitor segít meghatározni, hogy az adatbázis-kiszolgáló a felelős-e.

Azoknak az adatbázis-adminisztrátoroknak, akik nem dolgoznak a következővel: SQL Server Naponta az Activity Monitor könnyen hozzáférhető belépési pontot kínál a szerveraktivitás megértéséhez. Még a tapasztalt adatbázis-adminisztrátorok is használják ezt a szolgáltatást.tarkiindulópont a teljesítményvizsgálatokhoz.

1.3 Aktivitásfigyelő vs. más megfigyelőeszközök

Bár az Aktivitásfigyelő értékes, fontos megérteni, hogyan viszonyul más figyelési lehetőségekhez:

Aktivitásfigyelő vs. sp_WhoIsActive: Az Activity Monitor egy több panelből álló grafikus felületet biztosít, míg az sp_WhoIsActive egy átfogó tárolt eljárás, amely részletesebb információkat kínál egyetlen eredményhalmazban. Az sp_WhoIsActive az Activity Monitor által csoportosított konkrét várakozási típusokat jeleníti meg, és részletesebb blokkolási információkat nyújt.

Aktivitásfigyelő vs. sp_who2: A hagyományos sp_who2 parancs alapvető munkamenet-információkat jelenít meg, de az Activity Monitor továbbmegy, és rendezett, vizuális formátumban jeleníti meg a várakozási statisztikákat, a költséges lekérdezéseket és az I/O-metrikákat.

Aktivitásfigyelő vs. harmadik féltől származó eszközök: A kereskedelmi monitorozási megoldások, mint például a SolarWinds Database Performance Analyzer, olyan előzménykövetést, riasztásokat és fejlett elemzéseket kínálnak, amelyek az Activity Monitorban hiányoznak. Az Activity Monitor azonban nem igényel további felügyeletet.ost vagy telepítés.

1.4 Főbb előnyök adatbázis-adminisztrátorok számára

Az Activity Monitor számos előnnyel rendelkezik, amelyek nélkülözhetetlen adatbázis-nyilvántartó eszközzé teszik:

• Nulla Cost: Beépítettként SQL Server A Management Studio funkcióval nincs licencdíj vagy telepítési erőfeszítés.
• Valós idejű megfigyelés: Tekintse meg az aktuális szervertevékenységet azonnal, 1 másodperctől 1 óráig konfigurálható frissítési időközökkel.
• Integrált intézkedések: Kattintson a jobb gombbal a folyamatokra a munkamenetek leállításához, a lekérdezés részleteinek megtekintéséhez vagy az indításhoz SQL Server Profiler nyomkövetések – mindezt az eszközön belül.
• Többféle perspektíva: A szerver állapotát különböző szögekből tekintheti meg öt speciális panelen keresztül, amelyek mindegyike a teljesítmény egy adott aspektusára összpontosít.
• Gyors hibaelhárítás: Azonosítsa az m-etost a gyakori teljesítményproblémák perceken belül megoldhatók, ami lerövidíti a megoldás átlagos idejét.
• Alacsony belépési akadály: Nincs szükség haladó szintű ismeretekre az eszköz hatékony használatához, bár mélyebb ismeretekre van szükség. SQL Server A szakértelem segít az értelmezésben.

2. S megszerzésetarAktivitásfigyelővel

Mielőtt hatékonyan használhatná az Activity Monitort, meg kell értenie az előfeltételeket, a szükséges engedélyeket és az eszköz elindításának különböző módszereit.

2.1 Előfeltételek és rendszerkövetelmények

Használata SQL Server Aktivitásfigyelő, amire szükséged van SQL Server A Management Studio (SSMS) telepítve van a helyi gépen vagy egy ugrószerveren. Az Activity Monitor eszközt jelentősen áttervezték 2019-ben. SQL Server 2008, így az útmutatóban szereplő információk a következőkre vonatkoznak: SQL Server 2008 és újabb verziók.

Hálózati kapcsolattal kell rendelkeznie a következőhöz: SQL Server példány, amelyet monitorozni szeretne. A cloud-h esetébenosted adatbázisok esetén általában VPN-kapcsolatra vagy megfelelően konfigurált tűzfalszabályokra van szükség a példány eléréséhez.

Az Aktivitásfigyelő az összes kiadással működik. SQL Server, beleértve az Express, a Standard és az Enterprise verziókat. Maga az eszköz az SSMS-en belül fut a kliens gépen, így a szerver erőforrásait csak az általa végrehajtott monitorozási lekérdezések befolyásolják.

2.2 Szükséges engedélyek

A megfelelő engedélyek elengedhetetlenek az Aktivitásfigyelő megfelelő működéséhez. A megfelelő jogosultságok nélkül üres képernyő jelenhet meg, vagy hozzáférés megtagadva hibákat kaphat.

2.2.1 SZERVERÁLLAPOT MEGTEKINTÉSI Engedély

A SZERVER ÁLLAPOT MEGTEKINTÉSE Az engedély az Aktivitásfigyelő használatának elsődleges követelménye. Ez a szerverszintű engedély lehetővé teszi az összes aktív folyamat és a hozzájuk tartozó mérőszámok megtekintését.

Az engedély megadásához a szerver adminisztrátora a következő parancsot futtathatja:

GRANT VIEW SERVER STATE TO [YourLoginName];

A VIEW SERVER STATE (SZERVERÁLLAPOT MEGTEKINTÉSE) beállítás nélkül előfordulhat, hogy az Activity Monitor megnyílik, de egyik paneljén sem jelennek meg adatok.

2.2.2 Adatbázis-szintű jogosultságok

Az Adatfájl I/O panelen található információk megtekintéséhez további engedélyekre van szükség. Pontosabban az alábbi kombinációk egyikével kell rendelkeznie:

• LÉTREHOZ DATABÁZIS engedély, vagy
• BÁRMELY ADATBÁZIS MÓDOSÍTÁSA engedély, vagy
• BÁRMELY DEFINÍCIÓ MEGTEKINTÉSE engedély

Ezeket az engedélyeket össze kell kapcsolni a következőkkel: SZERVER ÁLLAPOT MEGTEKINTÉSE a teljes Aktivitásfigyelő funkcióért.

2.2.3 Engedélyekkel kapcsolatos hibaelhárítás

Ha az Aktivitásfigyelő megnyílik, de nem jelenít meg adatokat, az engedélyek aost gyakori ok. Ellenőrizze, hogy a bejelentkezési adataihoz tartozik-e a kiszolgáló szintjén a MEGTEKINTÉS SZERVER ÁLLAPOT jogosultság. Az engedélyeket a következő parancs futtatásával ellenőrizheti:

SELECT * FROM fn_my_permissions(NULL, 'SERVER');

Keresse a „VIEW SERVER STATE” bejegyzést a permission_name oszlopban. Ha hiányzik, vegye fel a kapcsolatot az adatbázis-adminisztrátorral, hogy engedélyezze.

2.3 Az Aktivitásfigyelő megnyitása az SSMS-ben

SQL Server A Management Studio négy különböző módszert kínál az Aktivitásfigyelő indítására, így rugalmasságot biztosít a munkafolyamat-beállításai alapján.

2.3.1 1. módszer: Az eszköztárról

Az Aktivitásfigyelő megnyitásának leggyorsabb módja az eszköztár ikon használata:

1. Csatlakozzon a SQL Server példányban SQL Server Menedzsment Stúdió.
2. Keresd meg az Aktivitásfigyelő ikont a szokásos eszköztáron (egy zöld lejátszás gombbal ellátott oszlopdiagramra hasonlít).
3. Kattintson az ikonra az Aktivitásfigyelő elindításához.

Ez a módszer a leggyorsabb, ha már az SSMS-ben dolgozik, és gyorsan ellenőriznie kell a kiszolgáló tevékenységét.

2.3.2 2. módszer: Az Objektumkezelőből

Az Aktivitásfigyelőt közvetlenül az Objektumkezelőből is elindíthatja:

1. Az Objektumkezelőben keresse meg a SQL Server a monitorozni kívánt példány.
2. Kattintson a jobb gombbal a példány nevére.
3. választ Activity Monitor a helyi menüből.

Ez a módszer akkor hasznos, ha több szerverhez csatlakozik, mivel biztosítja, hogy a megfelelő példányt figyelje.

2.3.3 3. módszer: Billentyűparancsok használata

Billentyűzetre fókuszáló felhasználók számára, SQL Server A Management Studio egy erre a célra szolgáló gyorsbillentyűt biztosít:

1. Győződjön meg arról, hogy az SSMS az aktív ablak, és hogy csatlakozik egy példányhoz.
2. Sajtó Ctrl + más + A.
3. Az Aktivitásfigyelő megnyílik az aktuálisan kiválasztott példányhoz az Object Explorerben.

Vegye figyelembe, hogy az Activity Monitor az Object Explorerben kiválasztott kiszolgálópéldányhoz fog csatlakozni, ezért a parancsikon használata előtt győződjön meg arról, hogy a megfelelő példányt választotta ki.

2.3.4 4. módszer: Az Opciók menüből (Starkonfiguráció)

Ha gyakran használod az Aktivitásfigyelőt, beállíthatod az SSMS-t úgy, hogy automatikusan elinduljon, valahányszor...taraz alkalmazás:

1. In SQL Server Management Studio, navigáljon ide Eszközök -> Opciók.
2. A Beállítások párbeszédpanelen bontsa ki a Környezet, Majd válassza ki Starcső.
3. Tól A starcső legördülő listából válassza ki Objektumkezelő és Tevékenységfigyelő megnyitása.
4. választ OK.

Amikor legközelebb elindítja az SSMS-t és csatlakozik egy szerverhez, az Activity Monitor automatikusan megnyílik az Object Explorer mellett.

3. Az Aktivitásfigyelő panelek ismertetése

Az Aktivitásfigyelő öt kibontható panelen rendszerezi az információkat, amelyek mindegyike más perspektívát nyújt a szerver tevékenységéről. Az egyes panelek megjelenítésének megértése kulcsfontosságú a hatékony hibaelhárításhoz.

3.1 Áttekintő panel

Az Áttekintés panel négy valós idejű grafikont jelenít meg, amelyek gyors áttekintést nyújtanak az Ön állapotáról. SQL Server például. Ezek a grafikonok konfigurálható időközönként frissülnek, és segítenek egy pillantással azonosítani a rendellenes mintákat.

3.1.1% Processzoridő

Ez a grafikon azt mutatja, hogy a processzor hány százalékban hajt végre nem tétlen szálakat a következőhöz: SQL Server példány az összes CPU-n. Az érték a következőt jelöli: SQL Servera processzor kihasználtságát, nem a teljes szerver CPU-használatát.

Ha a processzoridő folyamatosan 100% vagy ahhoz közeli értéket mutat, a szerver CPU-korlátozott. Ez nem hatékony lekérdezésekre, hiányzó indexekre vagy elégtelen hardverkapacitásra utalhat. A Legutóbbi költséges lekérdezések panelen azonosíthatja, hogy mely lekérdezések foglalják a processzoridőt.ost CPU.

3.1.2 Várakozó feladatok

Ez a mutató azon feladatok számát jeleníti meg, amelyek erőforrások felszabadítására várnak, mielőtt folytathatók lennének. A feladatok várhatnak CPU-ra, I/O-ra, memóriára vagy zárolásokra.

A várakozó feladatok következetesen magas száma erőforrás-versengést jelez. Az Erőforrás-várakozások ablaktábla további részleteket nyújt arról, hogy milyen típusú erőforrások okozzák a várakozásokat.

3.1.3 Adatbázis I/O (MB/s)

Ez a grafikon a memória és a lemez közötti adatátviteli sebességet mutatja. Kombinálja az olvasási és írási sebességet, megabájt/másodpercben mérve.

Az adatbázis I/O-ban tapasztalható kiugrások nagyméretű táblaellenőrzéseket végrehajtó lekérdezéseket, túlzott naplózási tevékenységet vagy ellenőrzőpont-műveleteket jelezhetnek. Az Adatfájl I/O panel adatbázis és fájl szerint lebontja az I/O-tevékenységet.

3.1.4 Kötegelt kérések/másodperc

Ez a mutató a következők számát jelenti: SQL Server A példány által másodpercenként fogadott kötegek száma. Egy köteg lehet egyetlen utasítás vagy több, együttesen elküldött utasítás.

Ez az érték képet ad a szerver teljes aktivitásáról. A kötegelt kérelmek számának hirtelen csökkenése a szokásos munkaidőben alkalmazáskapcsolati problémákra vagy felhasználók által tapasztalt problémákra utalhat.

3.1.5 Frissítési intervallumok beállítása

Testreszabhatja az Aktivitásfigyelő adatainak frissítési gyakoriságát:

1. Kattintson jobb gombbal az Áttekintés panel bármely pontjára.
2. választ Frissítési intervallum.
3. Válasszon egy intervallumot az előre definiált értékek közül: 1 másodperc, 5 másodperc, 10 másodperc (alapértelmezett), 30 másodperc, 1 perc vagy 1 óra.

A 10 másodpercnél rövidebb frissítési időközök beállítása növeli a szerver monitorozási terhelését. Nagy terhelés alatt álló éles rendszerek esetén érdemes 30 másodperces vagy hosszabb időközöket használni a hatás minimalizálása érdekében.

3.2 Folyamatok panel

A Folyamatok panel információkat jelenít meg a gépen jelenleg futó munkamenetekről. SQL Server Ez a panel elengedhetetlen annak azonosításához, hogy ki mit csinál, és a blokkoló problémák észleléséhez.

3.2.1 A folyamatinformációk megértése

A Folyamatok panel minden sora egy aktív munkamenetet jelöl a szerveren. A panel az összes adatbázis és az összes felhasználó munkameneteit megjeleníti, átfogó képet adva a szerver tevékenységéről.

A megjelenített információk tartalmazzák a bejelentkezési nevet, az alkalmazás nevét, a hostnév, az elért adatbázis és az aktuális parancs. Ez segít az adatbázis-tevékenységek összekapcsolásában adott felhasználókkal vagy alkalmazásokkal.

3.2.2 A főbb oszlopok magyarázata

A fő oszlopok megértése segít a folyamatinformációk hatékony értelmezésében:

• Munkamenet azonosító: Minden kapcsolat egyedi azonosítója. A rendszerfolyamatok negatív munkamenet-azonosítókat használnak.
• Felhasználói folyamat: Azt jelzi, hogy ez egy felhasználói munkamenet (Igen) vagy egy rendszerfolyamat (Nem).
• Belépés: A SQL Server bejelentkezési név vagy a munkamenethez társított Windows-fiók.
• adatbázis: A munkamenet aktuális adatbázis-kontextusa.
• Feladat állapota: Megjeleníti, hogy a munkamenet mit csinál jelenleg (FUT, FELFÜGGESZT, ALVÓ stb.).
• Parancs: A végrehajtandó parancs típusa (SELECT, INSERT, UPDATE stb.).
• Alkalmazás: A kapcsolatot létrehozó alkalmazás neve.
• Várakozási idő: Mennyi ideje (milliszekundumban) vár a munkamenet erőforrásokra.
• Várakozás típusa: Az az erőforrástípus, amelyre a munkamenet vár.
• CPU idő: A munkamenet által a csatlakozás óta felhasznált teljes CPU-idő.
• Memóriahasználat: A munkamenethez jelenleg lefoglalt memória mennyisége (KB-ban).

3.2.3 Szűrési és rendezési folyamatok

A Folyamatok panel hatékony szűrési lehetőségeket kínál, amelyek segítenek a releváns munkamenetekre koncentrálni:

1. Kattintson bármelyik oszlopfejlécben található legördülő menü nyílára.
2. A szűrő az adott oszlophoz elérhető értékeket jeleníti meg, beleértve a következőket: Hírek, Üresekés Nem üresek.
3. Válasszon ki adott értékeket, ha csak az adott munkamenetekre szeretné szűrni a megjelenítést.

Például szűrheti Feladat állapota csak a FUTÓ munkamenetek megjelenítéséhez, vagy szűréshez adatbázis egy adott adatbázisban végzett tevékenység megtekintéséhez.

Bármelyik oszlopot rendezheti a fejlécére kattintva. Kattintson egyszer a növekvő, kétszer a csökkenő sorrendhez.

3.2.4 Blokkoló és blokkolt munkamenetek azonosítása

A Folyamatok panel segít azonosítani azokat a blokkoló forgatókönyveket, ahol egy munkamenet megakadályozza a többi munkamenet folytatását:

• Blokkolta: Megjeleníti a munkamenetet blokkoló munkamenet azonosítóját. Ha ez az oszlop értéket tartalmaz, a munkamenet egy másik munkamenet által tartott zárolásra vár.
• Fejblokkoló: '1'-et jelenít meg, ha ez a munkamenet másokat blokkol, de maga nincs blokkolva. Ez a blokkoló lánc kiváltó oka.

Blokkolási probléma kivizsgálásához először azonosítsa a head blokkolót (a Head Blocker oszlopban '1'-gyel jelölt munkamenet), majd vizsgálja meg, hogy mit csinál, és döntse el, hogy hagyja-e befejeződni vagy leállítja-e.

3.2.5 Folyamatműveletek (Leállítás, Részletek, Nyomkövetés)

Az Aktivitásfigyelő lehetővé teszi az egyes munkamenetekhez kapcsolódó műveletek végrehajtását:

1. Kattintson jobb gombbal bármelyik munkamenetre a Folyamatok panelen.
2. Több lehetőséget is látni fogsz:
   • Részletek: Megjeleníti az adott munkamenet által utoljára végrehajtott parancsot.
   • Ölési folyamat: Leállítja a munkamenetet (óvatosan használja).
   • Nyomkövetési folyamat SQL Server Profilkészítő: Indított SQL Server Profiler és automatikusan szűr, hogy csak az adott munkamenetből származó tevékenységeket jelenítse meg.

A Részletek opció megjeleníti a parancs szövegét, de vegye figyelembe, hogy ez a utolsó parancs végrehajtva – lehet, hogy még nem fut. A Nyomkövetés opció különösen hasznos, ha látni szeretné a munkamenet által végrehajtott parancsok teljes sorozatát.

3.3 Erőforrás-várakozások panel

Az Erőforrás-várakozások panel összefoglalja a várakozási statisztikákat, megjelenítve, hogy milyen típusú erőforrás-munkamenetekre várnak.ost gyakran. Ez az információ kulcsfontosságú a teljesítménybeli szűk keresztmetszetek diagnosztizálásához.

3.3.1 A várakozási statisztikák megértése

Amikor SQL Server Ha a szerver nem tud azonnal jóváhagyni egy erőforrás-kérést (például zárolást, CPU-időt vagy memóriát), a kérő feladat várakozási állapotba kerül. A várakozási statisztikák nyomon követik ezeket a várakozási időszakokat, és segítenek megérteni, hogy a szerver mikor tölt időt várakozással a munka helyett.

Az Erőforrás-várakozások panel adatokat gyűjt a rendszerdinamikai felügyeleti nézetekből, például a sys.dm_os_wait_stats és a sys.dm_exec_requests nézetekből. Minden frissítési időközönként kiszámítja az aktuális és az előző pillanatkép közötti különbséget, megjelenítve az egyes várakozási típusok felhalmozódásának mértékét.

3.3.2 Várakozási kategóriák

Az Aktivitásfigyelő több száz egyedi várakozási típust csoportosít tágabb kategóriákba az értelmezés egyszerűsítése érdekében:

• CPU: CPU-idő felszabadulására váró feladatok.
• Puffer retesz: Rövid távú szinkronizációs objektumokra vár, amelyek védik a memóriában lévő adatlapok elérését. Ez a kategória magában foglalja az oldalzáras várakozásokat (PAGELATCH_*).
• Lock: Olyan várakozások, amelyeket olyan munkamenetek okoznak, amelyek olyan zárakat tartalmaznak, amelyekre más munkameneteknek szükségük van.
• memória: Várakozás a rendezés és a hasheléshez hasonló műveletekhez szükséges memória-engedélyezésekre.
• Hálózati I/O: Várakozások az adatok küldésére vagy fogadására az ügyfelektől.
• SQL CLR: A Common Language Runtime végrehajtásához kapcsolódó várakozások.

Bár ez a csoportosítás leegyszerűsíti a nézetet, fontos részleteket is elfed. Például a „Pufferzár” csoportosíthatja a PAGELATCH_SH, PAGELATCH_UP és PAGELATCH_EX várakozásokat, amelyek eltérő hatással vannak a teljesítményre.

3.3.3 A várakozási idő és a várakozási feladatok értelmezése

Az Erőforrás-várakozások panel két fő mutatót jelenít meg minden várakozási kategóriához:

• Összesített várakozási idő (ms): Az adott várakozási kategória aktuális frissítési intervallumában felhalmozódott összes milliszekundum.
• Várakozó feladatok: Az ebben a kategóriában jelenleg erőforrásokra váró feladatok száma.

A várakozási idő értéke különösen érdekes. Ha egy 10 másodperces frissítési intervallummal 20 000 ms várakozási időt látunk egy kategóriánál, az több egyidejű várakozást jelez (20 000 ms / 10 000 ms = 2 egyidejű várakozás átlaga az intervallum alatt).

3.3.4 Teljesítménybeli szűk keresztmetszetek azonosítása

Az Erőforrás-várakozások panel segítségével azonosíthatja, hogy a szerver mire fordítja az időt.ost várakozási idő:

1. Bontsa ki az Erőforrás-várakozások panelt.
2. Figyeld meg azokat a várakozási kategóriákat, amelyekben a legnagyobb várakozási idők halmozódnak fel.
3. Sorrend Összesített várakozási idő hogy mely erőforrások most korlátozva.

A magas pufferzáras várakozások gyakran a memóriában lévő adatlapokért folytatott versengést jeleznek, ami I/O szűk keresztmetszetekre vagy ideiglenes adatbázis-versengésre utalhat. A magas zárolási várakozások blokkolási problémákra utalnak. A magas memória-várakozások pedig a lekérdezési műveletekhez rendelkezésre álló elegendő memóriamennyiségre utalnak.

3.4 Adatfájl I/O panel

Az Adatfájl I/O panel a szerveren található egyes adatbázisfájlok lemeztevékenységét mutatja, segítve az I/O szűk keresztmetszetek azonosítását és a lemezkihasználtsági minták megértését.

3.4.1 Az I/O metrikák megértése

Az Adatfájl I/O panel számos metrikát jelenít meg minden adatbázisfájlhoz:

• adatbázis: Az adatbázis neve.
• Fájltípus: Vagy Adatok (beleértve a táblázatokat és indexeket), vagy Napló (tranzakciónapló).
• Logikai név: A logikai fájlnév, ahogyan az a SQL Server.
• MB/másodperc Olvasás: A fájlból beolvasott adatok sebessége.
• MB/másodperc írásban: Az adatok fájlba írásának sebessége.
• Válaszidő (ms): Az I/O műveletek átlagos válaszideje ezen a fájlon.

Ezek a mérőszámok ugyanolyan időközönként frissülnek, mint az Áttekintés panel, így valós idejű betekintést nyújt a lemeztevékenységbe.

3.4.2 I/O szűk keresztmetszetek azonosítása

Figyeljen az alábbi mintákra, amelyek I/O teljesítményproblémákra utalnak:

• Magas válaszidő: A 15-20 ms feletti válaszidők tartósan lassú lemez alrendszerekre utalnak. Az 50 ms feletti válaszidők komoly I/O szűk keresztmetszeteket jeleznek.
• Kiegyensúlyozatlan terhelés: Ha egy adatfájl jelentősen magasabb I/O sebességet mutat, mint az adatbázis többi adatfájlja, akkor előnyös lehet további fájlok hozzáadása a terhelés elosztása érdekében.
• Túlzott Tempdb aktivitás: A tempdb fájlok magas I/O sebessége gyakran azt jelzi, hogy a lekérdezések nagy köztes eredményhalmazokat hoznak létre, vagy nem hatékony végrehajtási terveket használnak.

3.4.3 Adatbázisfájl-elemzés

Az Adatfájl I/O panelen megismerheti, hogyan használják az adatbázisok a lemezerőforrásokat:

1. Bontsa ki az Adatfájl I/O panelt.
2. Sorrend MB/másodperc olvasás or MB/másodperc írási idő az m azonosításáraost aktív fájlok.
3. Jegyezze fel azokat a fájlokat, amelyek következetesen nagy aktivitást vagy hosszú válaszidőt mutatnak.
4. Hasonlítsa össze ezt az információt a Legutóbbi költséges lekérdezések panellel, hogy azonosítsa, mely lekérdezések okozzák az I/O terhelést.

3.5 Legutóbbi drága lekérdezések panel

A Legutóbbi drága lekérdezések panel gyakran az most értékes ablaktábla az alkalmazások teljesítményével kapcsolatos problémák elhárításához. Megjeleníti azokat a lekérdezéseket, amelyek jelentős szervererőforrásokat fogyasztanak, segítve az optimalizálási lehetőségek azonosítását.

3.5.1 A lekérdezési metrikák megértése

Az Aktivitásfigyelő számos mutatót jelenít meg minden egyes költséges lekérdezéshez:

• Kivégzések/perc: Hányszor futott le a lekérdezés az utolsó percben.
• CPU (ms/sec): A lekérdezés által másodpercenként felhasznált CPU-idő.
• Fizikai olvasás/másodperc: A lekérdezés során másodpercenként végzett fizikai lemezolvasások száma.
• Logikai írások/másodperc: Logikai írások száma (a gyorsítótár pufferelésére) másodpercenként.
• Logikai olvasás/másodperc: Logikai olvasások száma (a puffer gyorsítótárból) másodpercenként.
• Átlagos időtartam (ms): A lekérdezés átlagos végrehajtási ideje.
• Tervszám: A lekérdezéshez tartozó végrehajtási tervek száma a gyorsítótárban.

Ezek a mutatók nemcsak abban segítenek megérteni, hogy mely lekérdezések drágák, hanem miért drágák, és milyen gyakran közlekednek.

3.5.2 Rendezési beállítások

A Legutóbbi költséges lekérdezések panelt különböző mérőszámok szerint rendezheti, így különböző típusú problémákat találhat:

1. Kattintson bármelyik oszlop fejlécére az adott mutató szerinti rendezéshez.
2. A gyakori rendezési stratégiák a következők:
   • Rendezés CPU szerint: Az m-et használó lekérdezések kereséseost processzoridő.
   • Rendezés végrehajtások/perc szerint: Azonosítsa a túl gyakran futtatott lekérdezéseket.
   • Rendezés fizikai olvasmányok szerint: Keresse meg az m betűt okozó lekérdezéseketost lemez I/O.
   • Rendezés átlagos időtartam szerint: Hosszan futó lekérdezések megkeresése.

Teljesítményprobléma elhárításakor próbáljon meg több oszlop szerint rendezni, hogy különböző nézőpontokat kapjon. Egy mérsékelt CPU-használatú, de percenként rendkívül magas végrehajtási sebességű lekérdezés okozhatja a valódi problémát.

3.5.3 Lekérdezés szövegének megtekintése

Egy költséges lekérdezés mögötti tényleges SQL utasítás megtekintéséhez:

1. Kattintson a jobb gombbal a lekérdezés sorára a Legutóbbi drága lekérdezések panelen.
2. választ Lekérdezés szövegének szerkesztése.
   
3. Megnyílik egy új lekérdezési ablak, amelyen a teljes SQL utasítás látható.
   

Ez lehetővé teszi a lekérdezés logikájának vizsgálatát és a potenciális optimalizálási lehetőségek azonosítását. Ezután a lekérdezés szövegét másolhatja a módosított verziók teszteléséhez.

3.5.4 Végrehajtási tervek elemzése

A végrehajtási tervek megmutatják, hogyan SQL Server végrehajt egy lekérdezést, feltárva a hatékonyság hiányosságait, például a hiányzó indexeket vagy a nem megfelelő illesztési típusokat:

1. Kattintson a jobb gombbal a lekérdezés sorára a Legutóbbi drága lekérdezések panelen.
2. választ Végrehajtási terv megjelenítése.
   
3. SQL Server A Management Studio grafikusan ábrázolja a lekérdezés végrehajtását.
   

Keressen olyan műveleteket, amelyek a lekérdezés c nagy százalékát foglalják el.ost, figyelmeztetések hiányzó statisztikákról vagy indexekről, valamint váratlan táblabeolvasási műveletekről. Ezek gyakran jelzik, hogy az optimalizálási erőfeszítéseknek mire kell összpontosítaniuk.

3.5.5 Problémás lekérdezések azonosítása

Figyelje ezeket a mintákat a Legutóbbi drága lekérdezések panelen:

• Túlzott kivégzések: Egy percenként több ezerszer végrehajtódó lekérdezés N+1 lekérdezési problémára utalhat, ahol az alkalmazáskód egy cikluson belül hívja meg az adatbázist.
• Magas fizikai olvasmányok: A magas fizikai olvasási sebességű lekérdezések gyakran kerülnek lemezre, ami hiányzó indexekre vagy rosszul megírt lekérdezésekre utal.
• Magas CPU-teljesítmény alacsony időtartammal: Sok gyors lekérdezés, amelyek összességében sok CPU-t fogyasztanak, ugyanúgy befolyásolhatja a szerver teljesítményét, mint néhány lassú lekérdezés.
• Több terv száma: A sok végrehajtási tervvel rendelkező lekérdezések paraméter-szippantási problémákkal vagy nem paraméterezett lekérdezésekkel küzdhetnek, ami a terv gyorsítótárának felduzzadását okozhatja.

4. Az Aktivitásfigyelő használata a teljesítménybeli hibák elhárításához

Az Activity Monitor akkor ragyog igazán, ha szisztematikusan használjuk a teljesítményproblémák diagnosztizálására és megoldására. Ez a szakasz a gyakori hibaelhárítási forgatókönyveket és azok megközelítését tárgyalja.

4.1 Túlzott lekérdezés-végrehajtások diagnosztizálása

Egyikükost A gyakori teljesítményproblémák közé tartozik, hogy a lekérdezések sokkal gyakrabban futnak a szükségesnél, ami gyakran az alkalmazástervezési problémák miatt van.

4.1.1 Ismétlődő lekérdezések azonosítása

A túl gyakran végrehajtódó lekérdezések észleléséhez:

1. Nyissa meg az Aktivitásfigyelőt, és bontsa ki a Legutóbbi drága lekérdezések ablaktábla.
2. Sorrend Kivitelezések/perc (kivégzések percenként).
3. Keresd a legfelül található lekérdezéseket, amelyek végrehajtási száma indokolatlanul magasnak tűnik.
4. Kattintson a jobb gombbal a gyanús lekérdezésre, és válassza a Lekérdezés szövegének szerkesztése hogy megvizsgálja az SQL utasítást.

Például, ha azt látod, hogy egy egyszerű SELECT utasítás percenként 37 000-szer fut, felmerül a kérdés, hogy az alkalmazásnak valóban ilyen gyakran kell-e meghívnia ezt a lekérdezést.ost A percenként több ezernél többször végrehajtó lekérdezések vizsgálatot indokolnak.

4.1.2 A kiváltó ok elemzése

A túlzott lekérdezés-végrehajtások jellemzően a következő problémákból erednek:

• N+1 lekérdezési probléma: Az alkalmazáskód lekéri az elemek listáját, majd minden egyes elemhez külön lekérdezést hajt végre a kapcsolódó adatok lekéréséhez. Ez N további lekérdezést hoz létre, ahol N az elemek száma.
• Hiányzó gyorsítótárazás: Az alkalmazás lekérdezi az adatbázist olyan adatokért, amelyek rarely változások ahelyett, hogy gyorsítótárazná azokat az alkalmazásmemóriában.
• Szavazási ciklusok: A kód ismételten lekérdezi az adatbázist az állapotváltozások ellenőrzésével, ahelyett, hogy változásértesítéseket vagy üzenetsorokat használna.
• ORM-hatékonyság hiánya: Az Entity Framework és hasonló eszközök néha nem hatékony lekérdezési mintákat generálnak, amikor a fejlesztők nem értik, hogyan fordítják le a kódjukat SQL-re.

A kiváltó ok meghatározásához kövesse vissza a lekérdezést az alkalmazáskódig. Figyelje meg a következőt: Alkalmazás és a Belépés oszlopok a Folyamatok panelen, amikor a lekérdezés végrehajtódik. Jobb gombbal is kattinthat a folyamatra, és kiválaszthatja a Nyomkövetési folyamat SQL Server Profiler hogy lásd a hívásmintát.

4.1.3 Megoldások és legjobb gyakorlatok

Miután azonosította a túlzott lekérdezés-végrehajtásokat, vegye figyelembe az alábbi megoldásokat:

• Kötegelt feldolgozás: Módosítsa az alkalmazás kódját úgy, hogy több elemet kérjen le egyetlen lekérdezésben illesztések vagy IN záradékok használatával, ahelyett, hogy külön lekérdezéseket futtatna egy ciklusban.
• Eredmény gyorsítótárazása: Gyakran használt, ritkán változó adatok az alkalmazásmemóriában, megfelelő lejárati időkkel.
• Szíves betöltés: Konfigurálja az ORM-eket úgy, hogy lelkes betöltési stratégiákat használjanak, amelyek kevesebb, hatékonyabb lekérdezéssel kérik le a kapcsolódó adatokat.
• Lekérdezés paraméterezése: Győződjön meg arról, hogy a lekérdezések paramétereket használnak az értékek összefűzése helyett, ami javítja a terv gyorsítótárának újrafelhasználását és csökkenti a fordítási terhelést.

4.2 Blokkolási problémák kivizsgálása

Blokkolás akkor történik, amikor egy munkamenet olyan zárolásokat tartalmaz, amelyek megakadályozzák a többi munkamenet folytatását. Ez lassú alkalmazásválaszidőkben és frusztrált felhasználókban nyilvánul meg.

4.2.1 Blokkoló láncok azonosítása

A blokkolás észleléséhez és elemzéséhez:

1. Nyissa meg az Aktivitásfigyelőt, és bontsa ki a folyamatok ablaktábla.
2. Keressen olyan munkameneteket, amelyek értékei a következő kategóriákban találhatók: Blokkolta oszlop – ezek más munkamenetek által tartott zárolásokra várnak.
3. '1'-es számmal rendelkező munkamenetek keresése Fejblokkoló oszlop – ezek a blokkoló láncok kiváltó okai.
4. Jegyezze fel a Munkamenet azonosító a fejblokkolóé.
5. Kattintson jobb gombbal a fejblokkoló munkamenetre, és válassza a lehetőséget Részletek hogy lássa, milyen parancsot hajt végre.

A blokkoló lánc megértése kulcsfontosságú. A fő blokkolót kell megvizsgálnod, nem a későbbi blokkolt munkameneteket.

4.2.2 A zártípusok megértése

A Várakozás típusa A Folyamatok panelen található oszlop jelzi, hogy milyen típusú zárolási blokkolt munkamenetekre várnak:

• LCK_M_X: Kizárólagos zárolási várakozás, amelyet jellemzően UPDATE, DELETE vagy INSERT műveletek okoznak.
• LCK_M_S: Megosztott zárolásra vár, általában SELECT utasítások, amelyek kizárólagos zárolások feloldására várnak.
• LCK_M_U: Frissítési zárolási várakozás, egy közbenső zárolási típus, amelyet a frissítések során használnak.
• LCK_M_IX: Intent exkluzív zárolási várakozás, amely oldal- vagy sorszintű zárolási versengést jelez.

A Várakozási erőforrás Az oszlop azt mutatja, hogy melyik adatbázis-objektum van zárolva, így könnyebben megérthető, hogy melyik tábla vagy index érintett a versenyben.

4.2.3 Blokkolási problémák megoldása

Miután azonosította a blokkoló munkamenetet és annak okát, több lehetősége is van:

1. Várjon a befejezésre: Ha a head blokkoló egy jogos lekérdezést futtat, amely hamarosan befejeződik, akkor a legjobb, ha hagyjuk, hogy természetesen befejeződjön.
2. Öld meg a munkamenetet: Ha a head blokkoló elakadt, vagy egy megszakítandó lekérdezést futtat:
   • Kattintson a jobb gombbal a munkamenetre a Folyamatok panelen.
   • választ kill folyamat.
   • Erősítse meg a műveletet a párbeszédpanelen.
3. Lekérdezések optimalizálása: Ha a blokkolás ugyanazokkal a lekérdezésekkel ismétlődik, optimalizálja őket a zárolási időtartam csökkentése érdekében.
4. Izolációs szintek beállítása: Érdemes lehet az OLVASÁSOS PILLANATKÉP ELKÜLÖNLEGESÍTÉSE funkciót használni a blokkolás csökkentése érdekében az olvasási igényű munkaterhelések esetén.
5. Index hangolás: Indexek hozzáadásával felgyorsíthatja a lekérdezéseket, és csökkentheti a zárolások időtartamát.

4.3 Magas CPU-használat elemzése

Amikor az Áttekintés panelen a processzoridő következetesen 100%-on vagy ahhoz közel jelenik meg, meg kell határozni, hogy mely lekérdezések felelősek ezért, és meg kell határozni, hogy optimalizálhatók-e.

4.3.1 CPU-igényes lekérdezések azonosítása

A túlzott CPU-fogyasztású lekérdezések megkereséséhez:

1. Nyissa meg a Legutóbbi drága lekérdezések ablaktábla.
2. Sorrend CPU (ms/sec) lekérdezések megjelenítése az m használatávalost CPU-idő.
3. Vizsgálja meg a lista leggyakoribb lekérdezéseit.
4. Kattintson jobb gombbal a nagy CPU-igényű lekérdezésekre, és válassza a lehetőséget Lekérdezés szövegének szerkesztése az SQL utasítás megtekintéséhez.
5. választ Végrehajtási terv megjelenítése hogy megértsük, hogyan fut a lekérdezés.

Ne csak az egyes lekérdezések CPU-használatára figyelj, hanem a Kivitelezések/perc oszlop. Egy végrehajtásonként mérsékelt CPU-igényű, de percenként több ezerszer lefutó lekérdezés lehet a legnagyobb CPU-fogyasztó.

4.3.2 Lekérdezésoptimalizálási technikák

A CPU-fogyasztás csökkentésére szolgáló gyakori módszerek a következők:

• Hiányzó indexek hozzáadása: Az indexkeresések sokkal kevesebb CPU-t használnak, mint a táblakeresések. Keresse a hiányzó indexjavaslatokat a végrehajtási tervekben.
• Írd át a nem hatékony lekérdezéseket: Cserélje le a kurzorokat halmazalapú műveletekre, szüntesse meg a felesleges függvényeket a WHERE záradékokban, és távolítsa el a redundáns illesztéseket.
• Statisztikák frissítése: Az elavult statisztikák oka SQL Server nem hatékony végrehajtási tervek kiválasztásához. Futtassa az UPDATE STATISTICS parancsot az érintett táblákon.
• Adatmennyiség csökkentése: Adjon hozzá WHERE záradékokat az adatok korábbi szűréséhez, használjon TOP vagy OFFSET/FETCH utasításokat oldalszámozáshoz, és kerülje a SELECT * utasításokat.
• Paraméter szimatolás javítása: Használjon OPTION (RECOMPILE) metódust, lekérdezési tippeket vagy tervezési útmutatókat, ha a paraméterek szimatolása problémákat okoz.

4.4 Memóriaproblémák vizsgálata

A memóriahiány miatt a lekérdezések lemezre ömölhetnek, ami jelentősen rontja a teljesítményt. Az Aktivitásfigyelő segít azonosítani a memóriaigényes műveleteket.

4.4.1 A memóriametrikák megértése

A Memóriahasználat A Folyamatok panelen található oszlop az egyes munkamenetekhez lefoglalt memóriát mutatja kilobájtban. Egyetlen munkamenet magas memóriahasználata gyakran a következőket jelzi:

• Nagyméretű rendezési vagy hash műveletek, amelyek nem fértek el az eredetileg engedélyezett memóriában
• Hatalmas eredményhalmazokat lekérő lekérdezések
• A végrehajtási terv operátorainak sok másolatát létrehozó túlzott párhuzamosság
• Memóriaszivárgások a CLR tárolt eljárásaiban vagy függvényeiben

Az Erőforrás-várakozások panelen memória-várakozások jelenhetnek meg, ha a lekérdezések nem tudnak elegendő memória-engedélyt szerezni, és várniuk kell, amíg a memória elérhetővé válik.

4.4.2 Memóriaigényes lekérdezések azonosítása

A memóriaterhelést okozó lekérdezések megkereséséhez:

1. A folyamatok ablaktábla, rendezés szerint Memóriahasználat hogy lásd az m-et használó munkameneteketost memória.
2. Kattintson a jobb gombbal a nagy memóriahasználatú munkamenetekre, és válassza a lehetőséget Részletek hogy megtekinthesse a lekérdezéseiket.
3. A Legutóbbi drága lekérdezések ablaktáblában keressen magas értékű lekérdezéseket Logikai olvasások or Logikai írások, mivel ezek gyakran korrelálnak a memóriahasználattal.
4. Vizsgálja meg a memória-engedélyezéseket használó Sort és Hash Match operátorok végrehajtási terveit.

A végrehajtási tervekben „Memory Grant” figyelmeztetéseket vagy kiömlési figyelmeztetéseket mutató lekérdezések memórianyomási problémákat jeleznek.

4.5 Alkalmazásteljesítmény-problémák észlelése

Amikor a felhasználók lassú alkalmazásválaszidőket jelentenek, az Activity Monitor segít meghatározni, hogy az adatbázis a szűk keresztmetszet-e.

4.5.1 Az Aktivitásfigyelő és az alkalmazásproblémák összefüggésbe hozása

Az alkalmazás lassúságának vizsgálatához:

1. Jegyezze fel a felhasználók által jelentett problémák pontos időpontját és az érintett alkalmazásokat.
2. Nyissa meg az Aktivitásfigyelőt, és ellenőrizze a Áttekintés az adott időpontban megnövekedett erőforrás-növekedéseket jelző ablaktáblát.
3. A folyamatok ablaktábla, szűrés alapja Alkalmazás hogy csak az érintett alkalmazásból származó kapcsolatok jelenjenek meg.
4. Keresd a magas Várakozási idő értékek, amelyek az adatbázis késéseit jelzik.
5. Ellenőrizd a Legutóbbi drága lekérdezések az adott alkalmazás jelentős erőforrásokat fogyasztó lekérdezéseinek ablaktáblája.

Ha az adatbázis nem mutat szokatlan tevékenységet, miközben a felhasználók lassúságot tapasztalnak, a probléma valószínűleg az alkalmazáskódban, a hálózati késleltetésben vagy a kliensoldali teljesítményben rejlik.

4.5.2 Nem hatékony alkalmazási minták azonosítása

Az Activity Monitor számos anti-mintát tárt fel az alkalmazástervezésben:

• Chatty alkalmazások: Sok apró lekérdezés kevesebb, hatékonyabb lekérdezés helyett. A Legutóbbi Drága Lekérdezések között található magas kapcsolatszám és számos egyszerű lekérdezés jellemzi.
• N+1 lekérdezés: Egy lekérdezés, majd N további lekérdezés a kapcsolódó adatokhoz. Egyszerű lekérdezésként jelenik meg, percenként rendkívül magas végrehajtási aránnyal.
• Nagy eredményhalmazok: Az alkalmazások sokkal több adatot kérnek le, mint amennyire szükségük van. Keresse a magas Logikai olvasások egyszerű SELECT * lekérdezésekkel kombinálva.
• Hiányzó időtúllépések: Azok az alkalmazások, amelyek nem állítanak be parancsidőkorlátokat, határozatlan ideig nyitva hagyhatják a kapcsolatokat, ami hosszú ideig futó munkamenetként látható a Folyamatok panelen.

5. Alternatív módszerek: Aktivitásfigyelő adatok beszerzése T-SQL-en keresztül

Bár az Aktivitásfigyelő kényelmes grafikus felületet biztosít, néha szükség lehet az egyenértékű információk programozott lekérésére, vagy egyéni figyelési megoldások létrehozására.

5.1 Dinamikus kezelési nézetek (DMV-k) használata

SQL Server dinamikus felügyeleti nézeteken keresztül teszi elérhetővé a tevékenységi információkat, amelyeket az Activity Monitor a színfalak mögött kérdez le.

5.1.1 A tevékenységfigyelés kulcsfontosságú DMV-i

A most Az Activity Monitor funkcióinak replikálásához fontos DMV-k a következők:

• sys.dm_exec_requests: Megjeleníti az aktuálisan futó kéréseket a CPU, I/O és várakozási információkkal.
• sys.dm_exec_sessions: Munkamenet-szintű információkat tartalmaz, például bejelentkezési nevet, host név, és a program neve.
• sys.dm_os_wait_stats: Összesített várakozási statisztikákat biztosít a teljes példányra vonatkozóan.
• sys.dm_exec_query_stats: Összesített teljesítménystatisztikákat tartalmaz a gyorsítótárazott lekérdezésekhez.
• sys.dm_io_virtual_file_stats: Visszaadja az adatok és naplófájlok I/O statisztikáit.
• sys.dm_exec_sql_text: Lekéri egy adott sql_handle vagy plan_handle SQL szövegét.
• sys.dm_exec_query_plan: Visszaadja egy gyorsítótárazott lekérdezés végrehajtási tervét.

5.1.2 Minta lekérdezések folyamatinformációkhoz

A Folyamatok panel funkcióinak replikálásához a következő lekérdezéseket végezheti el:

SELECT 
    s.session_id AS [Session ID],
    CASE WHEN s.is_user_process = 1 THEN 'Yes' ELSE 'No' END AS [User Process],
    s.login_name AS [Login],
    ISNULL(CAST(r.blocking_session_id AS VARCHAR), '') AS [Blocked By],
    CASE 
        WHEN r2.session_id IS NOT NULL 
        AND (r.blocking_session_id = 0 OR r.session_id IS NULL) 
        THEN '1' 
        ELSE '' 
    END AS [Head Blocker],
    ISNULL(DB_NAME(r.database_id), '') AS [Database],
    ISNULL(t.task_state, '') AS [Task State],
    ISNULL(r.command, '') AS [Command],
    r.cpu_time AS [CPU Time],
    r.total_elapsed_time AS [Elapsed Time],
    r.wait_time AS [Wait Time],
    r.wait_type AS [Wait Type],
    s.memory_usage * 8 AS [Memory Use (KB)],
    s.host_name AS [Host Name],
    s.program_name AS [Application]
FROM sys.dm_exec_sessions s
LEFT JOIN sys.dm_exec_requests r ON s.session_id = r.session_id
LEFT JOIN sys.dm_exec_requests r2 ON r.session_id = r2.blocking_session_id
LEFT JOIN sys.dm_os_tasks t ON r.session_id = t.session_id
WHERE s.session_id != @@SPID
ORDER BY s.session_id;

5.1.3 Minta lekérdezések várakozási statisztikákhoz

A várakozási statisztikák megtekintéséhez, hasonlóan az Erőforrás-várakozások panelhez:

SELECT TOP 10
    wait_type AS [Wait Type],
    wait_time_ms / 1000.0 AS [Wait Time (sec)],
    waiting_tasks_count AS [Waiting Tasks],
    wait_time_ms / NULLIF(waiting_tasks_count, 0) AS [Avg Wait Time (ms)]
FROM sys.dm_os_wait_stats
WHERE wait_type NOT LIKE '%SLEEP%'
    AND wait_type NOT LIKE '%IDLE%'
    AND wait_type NOT LIKE '%QUEUE%'
ORDER BY wait_time_ms DESC;

5.2 Az sp_WhoIsActive használata

Az sp_WhoIsActive egy hatékony, közösség által létrehozott tárolt eljárás, amely egyetlen eredményhalmazban részletesebb információkat nyújt, mint az Activity Monitor.

5.2.1 Az sp_WhoIsActive telepítése

Az sp_WhoIsActive telepítéséhez:

1. Töltse le a legújabb verziót innen: http://whoisactive.com.
2. A letöltött fájl egy SQL szkript, amely az eljárás definícióját tartalmazza.
3. Nyisd meg a szkriptet SQL Server Menedzsment Stúdió.
4. Csatlakozzon a SQL Server példa.
5. Futtassa a szkriptet az eljárás létrehozásához a fő adatbázisban.
6. Adjon végrehajtási jogosultságokat a megfelelő felhasználóknak.

Mivel az sp_WhoIsActive telepítve van a masterben, bármely adatbázis-környezetből elérhető.

5.2.2 Alapvető használati példák

Az sp_WhoIsActive használatának legegyszerűbb módja a következő:

EXEC sp_WhoIsActive;

Ez egy eredményhalmazt ad vissza, amely az összes aktív munkamenetet mutatja a lekérdezésekkel, várakozási típusokkal, blokkolási információkkal és erőforrás-használattal együtt.

Egy 10 másodperces minta, amely az adott időszak aktivitását mutatja:

EXEC sp_WhoIsActive @delta_interval = 10;

Ez kiszámítja a deltákat olyan metrikákhoz, mint a CPU és az olvasási sebesség, megjelenítve, hogy mi történt az adott 10 másodperc alatt.

5.2.3 Speciális paraméterek

Az sp_WhoIsActive számos testreszabási paramétert támogat:

• @szűrő: Az eredményeket adott munkamenetek, adatbázisok vagy bejelentkezések alapján szűrheti.
• @szűrő_típusa: Adja meg, hogy mire vonatkozzon a szűrő (munkamenet, adatbázis, bejelentkezés stb.).
• @get_plans: A végrehajtási terveket is belefoglalja az eredményekbe (állítsa 1-re).
• @get_locks: Részletes zárolási információk megjelenítése (1-re állítva).
• @get_transaction_info: Tranzakció részleteinek megjelenítése (1-re állítva).
• @rendezési_sorrend: Rendezze az eredményeket különböző mérőszámok szerint (CPU, olvasási sebesség, időtartam stb.).
• @cél_tábla: Eredmények beillesztése egy táblázatba a korábbi nyomon követéshez.

Példa a CPU szerint rendezett csomagok bemutatására:

EXEC sp_WhoIsActive 
    @get_plans = 1,
    @sort_order = '[CPU] DESC';

5.3 Rendszerben tárolt eljárások használata

SQL Server hagyományos tárolt eljárásokat tartalmaz a tevékenység monitorozására, bár kevesebb információt nyújtanak, mint a DMV-k vagy az Activity Monitor.

5.3.1 sp_who és sp_who2

Az sp_who eljárás alapvető munkamenet-információkat jelenít meg:

EXEC sp_who;

Az sp_who2 eljárás valamivel részletesebb leírást ad:

EXEC sp_who2;

Mindkét eljárás mutatja a munkamenet-azonosítókat, a bejelentkezési neveket, a CPU-időt és a blokkolási információkat. Azonban hiányzik belőlük a DMV-ken vagy az Activity Monitoron keresztül elérhető részletesség. Ezek most hasznos gyors ellenőrzésekhez, amikor minimális információra van szüksége gyorsan.

5.3.2 Egyéb hasznos rendszereljárások

A monitorozáshoz szükséges további rendszerszintű eljárások a következők:

• sp_lock: Megjeleníti a zárolási információkat (elavult; helyette a sys.dm_tran_locks fájlt használja).
• sp_monitor: Statisztikákat jelenít meg a következőről: SQL Server aktivitást.
• sp_segítség: Objektumdefiníciókat és metaadatokat jelenít meg.
• DBCC SQLPERF: Megjeleníti a tranzakciónapló-terület kihasználtságát és a várakozási statisztikákat.

5.4 Egyéni monitorozó szkriptek létrehozása

Az Activity Monitor által nyújtottakon túlmutató, speciális monitorozást igénylő környezetekben egyéni megoldásokat hozhat létre DMV-k segítségével.

5.4.1 Teljes Aktivitásfigyelő Egyenértékű Szkript

Íme egy átfogó szkript, amely lemásolja az m-etost Aktivitásfigyelő funkció:

-- Processes Information
SELECT 
    s.session_id AS [Session ID],
    CONVERT(CHAR(1), s.is_user_process) AS [User Process],
    s.login_name AS [Login],
    ISNULL(CONVERT(VARCHAR, w.blocking_session_id), '') AS [Blocked By],
    CASE 
        WHEN r2.session_id IS NOT NULL 
        AND (r.blocking_session_id = 0 OR r.session_id IS NULL) 
        THEN '1' 
        ELSE '' 
    END AS [Head Blocker],
    ISNULL(DB_NAME(r.database_id), N'') AS [Database],
    ISNULL(t.task_state, N'') AS [Task State],
    ISNULL(r.command, N'') AS [Command],
    SUBSTRING(st.text, (r.statement_start_offset/2) + 1,
        ((CASE r.statement_end_offset 
            WHEN -1 THEN DATALENGTH(st.text)
            ELSE r.statement_end_offset 
        END - r.statement_start_offset) / 2) + 1) AS [Statement],
    st.text AS [Command Text],
    r.cpu_time AS [CPU Time (ms)],
    r.total_elapsed_time / 1000 AS [Elapsed Time (sec)],
    r.wait_time AS [Wait Time (ms)],
    r.wait_type AS [Wait Type],
    r.wait_resource AS [Wait Resource],
    s.memory_usage * 8 AS [Memory Use (KB)],
    s.host_name AS [Host Name],
    c.client_net_address AS [Net Address],
    s.program_name AS [Application]
FROM sys.dm_exec_sessions s
LEFT JOIN sys.dm_exec_requests r ON s.session_id = r.session_id
LEFT JOIN sys.dm_exec_requests w ON r.session_id = w.blocking_session_id
LEFT JOIN sys.dm_exec_requests r2 ON r.session_id = r2.blocking_session_id
LEFT JOIN sys.dm_os_tasks t ON r.session_id = t.session_id 
    AND r.request_id = t.request_id
LEFT JOIN sys.dm_exec_connections c ON s.session_id = c.session_id
OUTER APPLY sys.dm_exec_sql_text(r.sql_handle) st
WHERE s.session_id != @@SPID
ORDER BY s.session_id;

-- Recent Expensive Queries
SELECT TOP 20
    qs.execution_count / 
        DATEDIFF(MINUTE, qs.creation_time, GETDATE()) AS [Executions/min],
    qs.total_worker_time / 1000 AS [CPU Time (ms)],
    qs.total_physical_reads AS [Physical Reads],
    qs.total_logical_writes AS [Logical Writes],
    qs.total_logical_reads AS [Logical Reads],
    qs.total_elapsed_time / qs.execution_count / 1000 AS [Avg Duration (ms)],
    SUBSTRING(st.text, (qs.statement_start_offset/2) + 1,
        ((CASE qs.statement_end_offset 
            WHEN -1 THEN DATALENGTH(st.text)
            ELSE qs.statement_end_offset 
        END - qs.statement_start_offset) / 2) + 1) AS [Query Text]
FROM sys.dm_exec_query_stats qs
CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) st
WHERE qs.execution_count > 0
ORDER BY qs.total_worker_time DESC;

5.4.2 Monitorozás automatizálása SQL Agent feladatokkal

Egyéni monitorozási szkripteket ütemezhet a következővel: SQL Server Ügynök:

1. Hozz létre egy táblázatot a monitorozási eredmények tárolásához.
2. Módosítsa a monitorozási szkriptet az eredmények beszúrásához ebbe a táblázatba.
3. In SQL Server Management Studio, kibontás SQL Server Ügynök az Objektumkezelőben.
4. Kattintson a jobb gombbal Állások és válassza ki a Új Munka.
5. Konfigurálja a feladatot úgy, hogy a monitorozási szkript rendszeres időközönként fusson.
6. Állítson be riasztásokat vagy jelentéseket a gyűjtött adatok alapján.

Ez a megközelítés lehetővé teszi az előzménykövetést és a trendelemzést, amelyet az Activity Monitor nem biztosít.

6. Az aktivitásmérő korlátai és szempontjai

Bár az Aktivitásfigyelő értékes, a korlátainak ismerete segít abban, hogy megfelelően használhassa, és szükség esetén más eszközökkel egészíthesse ki.

6.1 Az Aktivitásfigyelő többletterhelésének megértése

Az Activity Monitor nem ingyenes – szervererőforrásokat fogyaszt az információk gyűjtése és megjelenítése. Ennek a többletterhelésnek a megértése segít felelősségteljesen használni.

6.1.1 A szerver erőforrásaira gyakorolt ​​hatás

Az Activity Monitor minden frissítéskor lekérdezéseket futtat a rendszer DMV-ken. Ezek a lekérdezések CPU-terhelést jelentenek, logikai olvasásokat generálnak, és rövid ideig zárolhatják a rendszertáblákat. A forgalmas szervereken ez a terhelés hatással lehet a teljesítményre.

A Folyamatok és a Legutóbbi Költséges Lekérdezések ablaktáblák különösen költségesek, mivel potenciálisan nagyméretű DMV-ket és gyorsítótár-táblákat kell átvizsgálniuk. Több ezer gyorsítótárazott lekérdezési tervvel rendelkező szervereken a Legutóbbi Költséges Lekérdezések frissítése több másodpercig is eltarthat.

A Microsoft dokumentációja figyelmeztet, hogy a 10 másodpercnél rövidebb frissítési időközök észrevehetően befolyásolhatják a szerver teljesítményét, különösen a már betöltött rendszereken.

6.1.2 Frissítési intervallum – ajánlott eljárások

Válassza ki a helyzetének megfelelő frissítési időközöket:

• 1-5 másodperc: Csak kritikus problémák azonnali hibaelhárítására alacsony terhelésű szervereken. Ne hagyja az Aktivitásfigyelőt ilyen időközönként futni.
• 10 másodperc (alapértelmezett): Ésszerű m számáraost hibaelhárítási forgatókönyvek és általános monitorozás.
• 30-60 másodperc: Jobb választás nagy terhelés alatt álló éles szerverekhez, vagy hosszabb ideig tartó monitorozáshoz.
• Csak manuális frissítés: Olyan helyzetekben, amikor folyamatos lekérdezés nélkül szeretné ellenőrizni az aktuális állapotot.

Mindig zárd be az Aktivitásfigyelőt, ha befejezted a vizsgálatot. Ne hagyd folyamatosan futni, különösen ne akkor, ha különböző felhasználók több példányban futtatják.

6.2 Várakozási típus csoportosítási problémák

Az Activity Monitor várakozási idők kategorizálására szolgáló megközelítése, bár leegyszerűsíti a nézetet, elfedheti a fontos diagnózisokat.ostic információk.

6.2.1 Hogyan várakozik az Aktivitásfigyelő Csoportok?

SQL Server Az Activity Monitor több száz különböző várakozási típust követ nyomon, amelyek mindegyike egy adott erőforrást vagy állapotot jelöl. Az Activity Monitor ezeket tág kategóriákba csoportosítja, például „Pufferzár”, „Zárolás” és „Memória”.

Például a „Pufferzár” kategória magában foglalja a PAGELATCH_SH, PAGELATCH_UP, PAGELATCH_EX és számos más specifikus várakozási típust. Bár mindegyik az oldal elérésével kapcsolatos, eltérő okaik és megoldásaik vannak.

A Microsoft nem dokumentálja pontosan, hogy mely várakozási típusok melyik kategóriába tartoznak, így nehéz megérteni, hogy mit is látunk valójában.

6.2.2 Hiányzó várakozási típusok

Az Aktivitásfigyelő nem jeleníti meg az összes várakozási típust. Most Figyelemre méltó, hogy gyakran kihagyja a CXPACKET várakozásokat, amelyek párhuzamos lekérdezés-végrehajtást jeleznek. A CXPACKET várakozások gyakoriak és általában nem okoznak problémát, de jelenlétük ismerete segít megérteni a munkaterhelés jellemzőit.

Amikor az Activity Monitor a „Buffer Latch”-et mutatja a legnagyobb várakozási időként, de más eszközök a CXPACKET-et dominálják, az eltérés az Activity Monitor szűrési és csoportosítási logikájából adódik.

6.2.3 Miért fontosak a specifikus várakozási típusok?

A várakozási típus ismerete fontos a hibaelhárítás szempontjából:

• PAGELATCH_EX: Gyakran tempdb-verziót jelez az elosztási oldalakon. A megoldás további tempdb adatfájlok hozzáadását jelenti.
• PAGELATCH_SH: A felhasználói táblázatokban található „forró oldalakra” utalhat. A megoldás particionálást vagy index-átszervezést foglal magában.
• OLDAL_FELFELÉ: Gyakori a frissítések során. Inkább normál működésre utalhat, mint problémára.

Az Activity Monitor mindezeket a „Pufferzár” alá csoportosítja, ami megnehezíti a diagnózist. Az olyan eszközök, mint az sp_WhoIsActive és a DMV lekérdezések, a várakozási típusok specifikus megjelenítését mutatják.

6.3 Adatok pontossága és időszerűsége

Az Activity Monitor közel valós idejű képet nyújt, de a „közel” a kulcsszó. Az adatgyűjtési módszerének megértése segít az eredmények helyes értelmezésében.

6.3.1 Pillanatfelvétel vs. folyamatos monitorozás

Az Aktivitásfigyelő minden frissítési időközönként pillanatképeket jelenít meg. A pillanatképek között bekövetkező eseményeket nem rögzíti. Ha egy lekérdezés 2 másodpercig fut, és 10 másodpercenként frissít, akkor az időzítéstől függően előfordulhat, hogy csak egyszer vagy egyáltalán nem jelenik meg.

Ez azt jelenti, hogy az Activity Monitor kiválóan felderíti az állandó problémákat (percekig tartó blokkolás, folyamatosan magas CPU-terhelés), de az átmeneti problémákat (rövid leállások, alkalmi lekérdezési csúcsok) esetleg nem veszi észre.

6.3.2 Összesítés és mintavételezés

A Legutóbbi Drága Lekérdezések panel a lekérdezési tervek gyorsítótárba kerülése óta összesített adatokat jeleníti meg. Két azonos, eltérő paraméterértékekkel rendelkező lekérdezés egy sorként jelenik meg, ha közös tervet osztanak meg. Ez az összesítés elfedheti az adott paraméterkombinációkkal kapcsolatos problémákat (paraméter-szivárgási problémák).

Az Erőforrás-várakozások panel pillanatképek összehasonlításával számítja ki a várakozási időket. Ha a várakozási statisztikák visszaállnak a pillanatképek között (rarde lehetséges), a kiszámított díjak helytelenek lehetnek.

6.4 Mikor NEM szabad használni az Aktivitásfigyelőt

Az Activity Monitor nem minden monitorozási forgatókönyvhöz megfelelő. Ismerje fel, mikor a jobb választás az alternatív eszközök.

6.4.1 Történeti elemzési követelmények

Az Aktivitásfigyelő csak az aktuális vagy legutóbbi tevékenységeket mutatja. Nem tárol előzményadatokat. Ha napok vagy hetek trendjeit kell elemeznie, az aktuális teljesítményt össze kell hasonlítania az alapértékekkel, vagy jelentéseket kell készítenie a teljesítménymintázatokról, az Aktivitásfigyelő nem elegendő.

Történeti elemzéshez használja SQL Serverbeépített Teljesítmény-irányítópult, kibővített események fájllal targets, vagy harmadik féltől származó monitorozási megoldások.

6.4.2 Részletes várakozási statisztikákra vonatkozó igények

Ha a várakozási típus pontos információjára van szüksége a speciális finomhangoláshoz, az Activity Monitor csoportosítása és szűrése nem teszi ezt megfelelővé. Használjon közvetlenül DMV-lekérdezéseket, vagy az sp_WhoIsActive függvényt.

Átfogó várakozási statisztikai elemzéshez kérdezze le közvetlenül a sys.dm_os_wait_stats fájlt, és manuálisan szűrje ki a jóindulatú várakozásokat.

6.4.3 Éles szerverrel kapcsolatos szempontok

Nagy terhelés alatt álló éles szervereken az Activity Monitor terhelése problémát okozhat. Több adatbázis-adminisztrátornak nem szabad egyszerre futtatnia az Activity Monitort ugyanazon a szerveren.

Éles környezetű monitorozáshoz érdemes megfontolni a könnyűsúlyú alternatívákat, például az ütemezett DMV-pillanatképeket, amelyeket egy monitorozási adatbázisban tárolnak, vagy csak olvasható útválasztást használni a másodlagos replikák monitorozásához Always On konfigurációkban.

7. Az Aktivitásfigyelő használatának ajánlott gyakorlatai

A legjobb gyakorlatok betartása biztosítja, hogy a lehető legtöbbet hozza ki az Activity Monitorból, miközben minimalizálja a szervereire gyakorolt ​​negatív hatásokat.

7.1 Mikor használjuk az Aktivitásfigyelőt

Az Aktivitásfigyelő bizonyos helyzetekben ragyog. Használd, amikor az erősségei összhangban vannak az igényeiddel.

7.1.1 Valós idejű teljesítményproblémák

Az Aktivitásfigyelő ideális megoldás, ha a felhasználók jelenleg problémákat tapasztalnak, és azonnal diagnosztizálni kell a problémát. A valós idejű nézet segít látni, hogy mi történik éppen.

Amikor olyan hívást kap, hogy „az alkalmazás lassú”, az Aktivitásfigyelő megnyitásának kell lennie az első lépések egyikének. Gyorsan megállapíthatja, hogy az adatbázis foglalt, blokkolt vagy tétlen.

7.1.2 Alkalmazáslassulás-vizsgálat

Amikor egy adott alkalmazás nem reagál, az Aktivitásfigyelő segít megállapítani, hogy az ok az adatbázis-problémák-e. Szűrje a Folyamatok panelt alkalmazásnév szerint, hogy csak az adott alkalmazás adatbázis-tevékenységét lássa.

Ha az alkalmazás nem mutat adatbázis-tevékenységet, miközben a felhasználók problémákat jelentenek, a probléma máshol keresendő a veremben. Ha kiterjedt blokkolást vagy költséges lekérdezéseket tapasztal, akkor megtalálta a bűnöst.

7.1.3 Gyors állapotfelmérések

Az Aktivitásfigyelő kiváló irányítópultot biztosít a gyors állapotellenőrzésekhez a rutin adminisztráció során. Nyissa meg, tekintse meg az Áttekintő grafikonokat, és ellenőrizze, hogy nincs-e semmi rendellenes.

Ez a felületes ellenőrzés másodperceket vesz igénybe, és feltárhatja a problémákat, mielőtt azok kritikussá válnának. Tegye a napi rutin részévé.

7.2 Optimális konfigurációs beállítások

Az Aktivitásfigyelő megfelelő konfigurálása javítja mind a hasznosságát, mind az erőforrás-fogyasztását.

7.2.1 Ajánlott frissítési intervallumok

Igazítsa a frissítési intervallumot a céljához:

• Aktív hibaelhárítás: 10 másodperc jó válaszidőt biztosít elfogadható terhelés mellett.
• Kiterjesztett megfigyelés: A 30-60 másodperces intervallum csökkenti a szerverre gyakorolt ​​hatást hosszabb megfigyelési időszakok során.
• Kritikus probléma diagnózisa: Az 5 másodperc nagy részletességet biztosít, amikor minden másodperc számít, de rövid ideig használható.
• Rendszeres egészségügyi ellenőrzések: Manuális frissítés (1 órás időközönként), ha nem nézed aktívan a videót.

Ne felejtsd el bezárni az Aktivitásfigyelőt, ha befejezted. Ha hosszú intervallumra állítod be, majd elfelejted, az szerver erőforrásait pazarolja.

7.2.2 Szűrési stratégiák

Használjon szűrőket a releváns információkra való összpontosításhoz és a kognitív terhelés csökkentéséhez:

• Folyamatok szűrése a következő szerint: adatbázis csak adott adatbázisokon végzett tevékenységek megtekintéséhez.
• Szűrés Belépés egy adott felhasználó tevékenységének nyomon követésére.
• Szűrés Feladat állapota = FUT az üresjárati munkamenetek elrejtéséhez.
• Szűrés Alkalmazás hogy elkülönítse a forgalmat bizonyos programoktól.
• Csak a nem üres elemek megjelenítése Blokkolta hogy csak a blokkoló helyzeteket lássa.

7.2.3 Oszlopkijelölés és rendezés

Szisztematikus megközelítés kidolgozása az Aktivitásfigyelő adatainak áttekintéséhez:

1. Start áttekintéssel: Ellenőrizze a grafikonokat nyilvánvaló kiugrások vagy rendellenességek szempontjából.
2. Blokkoló folyamatok ellenőrzése: Rendezze munkamenet-azonosító szerint, majd keresse meg a Blokkolt értékeket.
3. Erőforrás-várakozások áttekintése: Rendezés a kumulatív várakozási idő szerint az erőforrás-szűk keresztmetszetek azonosításához.
4. Drága lekérdezések elemzése: Rendezd a különböző metrikák (CPU, végrehajtások, olvasások) alapján a különböző problématípusok megtalálásához.
5. Ellenőrizze az I/O panelen: Erősítse meg, hogy az I/O-intenzív lekérdezések összefüggésben állnak-e a magas lemeztevékenységgel.

7.3 Integráció más eszközökkel

Az Activity Monitor egy szélesebb eszközkészlet részeként működik a legjobban, mint önálló megoldásként.

7.3.1 Használat a következővel: SQL Server Profiler

Aktivitásfigyelő és SQL Server A profilkészítők jól kiegészítik egymást. Amikor problémás munkamenetet azonosít az Aktivitásfigyelőben, kattintson rá jobb gombbal, és válassza a Nyomkövetési folyamat SQL Server Profiler.

Ez elindítja a Profilert, amelynek szűrői már konfigurálva vannak, hogy csak az adott munkamenet tevékenységét rögzítsék. Látható a végrehajtott utasítások teljes sorozata, az időzítési információk és a hibaüzenetek – olyan részletek, amelyeket az Aktivitásfigyelő nem biztosít.

Ha többet szeretne megtudni SQL Server Profiler képességekről és fejlett nyomkövetési technikákról lásd a átfogó SQL Server Profilkészítő útmutató.

7.3.2 Kiegészítés kiterjesztett eseményekkel

Az Extended Events alacsony terhelésű, részletes monitorozást kínál, amely rögzíti azokat az információkat, amelyeket az Activity Monitor nem tud. Hozzon létre Kiterjesztett esemény munkameneteket bizonyos események, például holtpontok, hosszan futó lekérdezések vagy túlzott újrafordítások nyomon követésére.

Az Aktivitásfigyelőt azonnali vizsgálatokhoz, a Kibővített eseményeket pedig folyamatos figyeléshez és előzményelemzéshez használhatja. A két eszköz eltérő igényeket elégít ki.

Ha többet szeretne megtudni SQL Server Kiterjesztett eseménykezelési képességekről és fejlett monitorozási technikákról lásd a átfogó SQL Server Bővített események kalauza.

7.3.3 Harmadik féltől származó monitorozási megoldások

A kereskedelmi eszközök, mint például a SolarWinds Database Performance Analyzer, a Redgate SQL Monitor és a Quest Spotlight olyan funkciókat kínálnak, amelyek az Activity Monitorban hiányoznak: riasztások, előzménytrendek, kapacitástervezés és automatizált diagnosztika.ostics.

Ezek az eszközök értékes kiegészítői az Activity Monitornak, nem pedig helyettesítői annak. Az Activity Monitor akkor is hasznos marad a gyors ellenőrzésekhez és vizsgálatokhoz, ha kifinomult felügyeleti eszközök állnak rendelkezésre.

7.4 gyakori hiba, amit el kell kerülni

Az Aktivitásfigyelő gyakori hibáinak megértése segít abban, hogy hatékonyabban használhassa azt.

7.4.1 Az Aktivitásfigyelő folyamatos futtatása

A most Gyakori hiba, hogy megnyitjuk az Aktivitásfigyelőt, és határozatlan ideig futtatjuk. Ez pazarolja a szerver erőforrásait, és kevés értéket képvisel, mivel nem figyeljük aktívan a folyamatot.

Zárd be az Aktivitásfigyelőt, ha nem használod aktívan. Ha folyamatos figyelésre van szükséged, ehelyett vezess be egy megfelelő figyelési megoldást ütemezett adatgyűjtéssel.

7.4.2 Túlzottan támaszkodunk csak az Aktivitásfigyelőre

Az Activity Monitor egyetlen perspektívát kínál a szerver állapotára vonatkozóan. Ne hagyatkozzon kizárólag erre. Egészítse ki a Windows Performance Monitorral az operációs rendszer szintű mérőszámokért, a Extended Events segítségével a részletes nyomon követésért, és a végrehajtási terv elemzésével a lekérdezések finomhangolásához.

Az Aktivitásfigyelő segít a problémák azonosításában, de megoldásuk gyakran további eszközöket és mélyebb elemzést igényel.

Tudjon meg többet SQL Server teljesítményfigyelő a miénkben teljes útmutató.

7.4.3 A történelmi trendek figyelmen kívül hagyása

Az Aktivitásfigyelő mutatja az aktuális állapotot, de a teljesítményproblémáknak gyakran csak időbeli mintázataik vannak. Gyűjtsön előzményadatokat, hogy összehasonlíthassa az aktuális mutatókat az alapértékekkel, és trendeket azonosíthasson.

Történelmi kontextus nélkül lehet, hogy nem veszi észre, hogy a mai „normális” CPU-használat 30%-kal magasabb, mint a múlt havi alapérték, ami fokozatos romlást jelez.

8. Az Aktivitásfigyelővel kapcsolatos problémák elhárítása

Maga az Aktivitásfigyelő is problémákba ütközik időnként. Ezen problémák elhárításának ismerete segít megelőzni a bosszúságot.

8.1 Az Aktivitásfigyelő nem nyílik meg, vagy nem jelenít meg adatokat

Amikor az Aktivitásfigyelő megnyílik, de üres paneleket jelenít meg, vagy egyáltalán nem nyílik meg, több tényező is közrejátszhat.

8.1.1 Engedélyezési problémák

A most Az Aktivitásfigyelő problémáinak gyakori oka a nem megfelelő jogosultságok. Az ellenőrzéshez és megoldáshoz:

1. Ellenőrizd a szerver szintű jogosultságaidat:

   SELECT * FROM fn_my_permissions(NULL, 'SERVER')
   WHERE permission_name = 'VIEW SERVER STATE';
   

2. Ha nem ad vissza sorokat, akkor nincs MEGTEKINTÉSI SZERVER ÁLLAPOT jogosultsága.
3. Kérjen engedélyt a szerver adminisztrátorától:

   USE master;
   GRANT VIEW SERVER STATE TO [YourLogin];
   

4. Az engedélyek megadása után zárja be, majd nyissa meg újra az Aktivitásfigyelőt.

8.1.2 Verziókompatibilitási problémák

Egy régebbi verzió használata SQL Server Management Studio egy újabbhoz való csatlakozáshoz SQL Server verzió az Aktivitásfigyelő hibáit okozhatja. Előfordulhat, hogy az eszköz nem érti az új várakozási típusokat vagy a rendszernézet oszlopait.

Mindig olyan SSMS verziót használjon, amely megegyezik a sajátjával, vagy újabb, mint SQL Server verzió. A Microsoft a legújabb SSMS-t ingyenesen, a SQL Server maga.

8.1.3 Tűzfal és hálózati problémák

Az Aktivitásfigyelőhöz internetkapcsolat szükséges. SQL Server példány szabványos portokon (alapértelmezés szerint 1433). Ha az Objektumkezelőn keresztül tud csatlakozni, de az Aktivitásfigyelő hibát jelez, előfordulhat, hogy a tűzfalszabályok blokkolják az adott kapcsolatokat.

Győződjön meg arról, hogy az ügyfele el tudja érni a SQL Server gép minden szükséges porton. Ellenőrizze mind a Windows tűzfalat, mind az esetleges hálózati tűzfalakat a kliens és a szerver között.

8.2 Aktivitásfigyelő tartósan szüneteltetve

Gyakori probléma, különösen a SQL Server 2019-ben az Activity Monitor szüneteltetett állapotban nyílik meg, és nem hajlandó folytatni.

8.2.1 A szüneteltetett állapot megértése

Amikor az Aktivitásfigyelő szünetel, minden panelen a „Szüneteltetett” állapot látható, egy folytatás gombbal, amely esetleg nem működik. Ez megakadályozza, hogy bármilyen szervertevékenységet lásson.

A szüneteltetett állapot általában engedélyezési problémák, távoli kapcsolati korlátozások vagy SSMS verzióhibák miatt következik be, nem pedig szándékos szüneteltetési művelet miatt.

8.2.2 Gyakori okok

Az Aktivitásfigyelő a következők miatt válthat állandó szüneteltetett állapotra:

• Hiányzik a MEGTEKINTÉSI SZERVER ÁLLAPOT jogosultság az újonnan hozzáadott paneleken. SQL Server verzió
• Távoli kapcsolatok letiltva a következőn: SQL Server példa
• Hitelesítési hibák adott rendszerlekérdezéseknél
• Hibák bizonyos SSMS-buildekben, különösen a 18.0-tól 18.3-ig terjedő verziókban
• Kapcsolódási problémák a kliens és a szerver között

8.2.3 Megoldási lépések

Az Aktivitásfigyelő szüneteltetett állapotával kapcsolatos problémák megoldása:

1. SSMS frissítése: Töltse le és telepítse a legújabbakat SQL Server A Management Studio verziója a Microsoft weboldaláról származik. Számos szüneteltetett állapottal kapcsolatos hibát kijavítottak a későbbi kiadásokban.
2. Engedélyek ellenőrzése: Győződjön meg arról, hogy rendelkezik a SZERVER ÁLLAPOT MEGTEKINTÉSE és a MEGHATÁROZÁSOK MEGTEKINTÉSE jogosultságokkal.
3. Távoli kapcsolatok ellenőrzése: Ellenőrizze, hogy a SQL Server A példány távoli kapcsolatokat engedélyez:

   EXEC sp_configure 'remote access';
   

   Ha az érték 0, kérje meg a rendszergazdát, hogy engedélyezze.

4. Restart SSMS: Néha egyszerűen csak be kell zárni az összes ablakot és újraindítanitarting SQL Server A Management Studio megoldja a problémát.
5. Kapcsolódás Windows hitelesítéssel: SQL-hitelesítés használata esetén próbálja ki a Windows-hitelesítést, mivel ez néha megkerüli a hitelesítéssel kapcsolatos szüneteltetési problémákat.

8.3 Teljesítményproblémák az Aktivitásfigyelő használatakor

Ha maga az Aktivitásfigyelő lelassul, vagy a szerver teljesítményének romlását okozza, akkor módosításra van szükség.

8.3.1 A felügyeleti többletterhelés csökkentése

Az Aktivitásfigyelő hatásának minimalizálása:

1. Növelje a frissítési időközt 30 másodpercre vagy 1 percre.
2. A nem használt ablaktáblákat az összecsukás gombra kattintva zárhatja be.
3. Amikor a panelek össze vannak csukva, az Aktivitásfigyelő nem kérdez le adatokat róluk.
4. Kerülje több Activity Monitor példány egyidejű futtatását.
5. Zárja be teljesen az Aktivitásfigyelőt, amikor nem vizsgálja aktívan a problémákat.

8.3.2 Alternatív könnyűsúlyú monitorozási módszerek

Ha az Aktivitásfigyelő túl erőforrás-igényes a környezetedhez, fontold meg az alternatívákat:

• Közvetlenül lekérdezheti a DMV-ket: Írj olyan T-SQL lekérdezéseket, amelyek csak a szükséges információkat kérik le.
• Használja az sp_WhoIsActive függvényt: Ez a tárolt eljárás nagymértékben optimalizált, és jellemzően alacsonyabb terheléssel jár, mint az Activity Monitor.
• Mintavételezés megvalósítása: SQL Agent-feladatok ütemezése, amelyek rendszeres időközönként pillanatképeket rögzítenek a DMV-adatokról, és táblázatokban tárolják az eredményeket későbbi elemzés céljából.
• Másodlagos replikák monitorozása: In Mindig bekapcsolt rendelkezésre állási csoportok, futtassa az Aktivitásfigyelőt egy olvasható másodlagos tárolón az elsődleges helyett.

8.4 Pontatlan vagy hiányzó információk

Az Aktivitásfigyelő néha olyan információkat jelenít meg, amelyek helytelenek vagy hiányosak.

8.4.1 Adatok ellenőrzése DMV-kkel

Ha az Aktivitásfigyelő eredményei gyanúsnak tűnnek, ellenőrizze azokat az alapul szolgáló DMV-k közvetlen lekérdezésével. Ha például a Folyamatok panel nem mutat blokkolást, de a felhasználók jelentik, akkor a következő lekérdezéssel ellenőrizze:

SELECT 
    blocking_session_id,
    session_id,
    wait_type,
    wait_time,
    wait_resource
FROM sys.dm_exec_requests
WHERE blocking_session_id != 0;

Ha ez a lekérdezés olyan blokkolást mutat, amelyet az Activity Monitor nem vett figyelembe, akkor megerősített egy megjelenítési problémát.

8.4.2 Az adatfrissítési időzítés megértése

Ne feledd, hogy az Aktivitásfigyelő pillanatképeket jelenít meg. A frissítési időközök között lefutott lekérdezés nem jelenik meg a Legutóbbi költséges lekérdezések között, kivéve, ha a végrehajtási terve a gyorsítótárban marad.

Hasonlóképpen, az Erőforrás-várakozások panelen található várakozási statisztikák az utolsó pillanatkép óta felhalmozódott adatokat tükrözik. A gyorsan változó munkaterhelések minden frissítéskor eltérő mintákat mutathatnak.

9. Haladó aktivitásfigyelő technikák

A tapasztalt adatbázis-adminisztrátorok kifinomult módon használják az Activity Monitort a diagnózis maximális hatékonyságának kinyerésére.ostic érték.

9.1 Több panel egyesítése a kiváltó ok elemzéséhez

Az Aktivitásfigyelő igazi ereje akkor mutatkozik meg, amikor több panelen keresztül összeveted az információkat, hogy megértsd az összetett teljesítményproblémákat.

9.1.1 Várakozások összefüggésbe hozása folyamatokkal

Amikor az Erőforrás-várakozások ablaktábla magas várakozási időket mutat egy kategóriában, a Folyamatok ablaktábla segítségével azonosíthatja, hogy mely munkamenetek tapasztalják ezeket a várakozásokat:

1. Figyelje meg a magas összesített várakozási idővel rendelkező várakozási kategóriát (pl. „Zár”).
2. Váltson a Folyamatok panelre.
3. Sorrend Várakozás típusa a munkamenetek csoportosítása az aktuális várakozási idejük szerint.
4. Keressen olyan munkameneteket, amelyek a problémás kategóriába tartozó várakozási típusokat mutatnak.
5. Ezekhez a foglalkozásokhoz vizsgálja meg a Várakozási erőforrás oszlopban látható, hogy mely adatbázis-objektumok érintettek.
6. Kattintson a jobb gombbal, és válassza a lehetőséget Részletek a lekérdezés szövegének megtekintéséhez.

Ez a korreláció segít áttérni a „zárolásra várunk” állapotról az „ez a konkrét lekérdezés zárolásokra vár ezen a táblán” állapotra.

9.1.2 Költséges lekérdezések összekapcsolása I/O problémákkal

Amikor az Adatfájl I/O ablaktábla nagy mennyiségű lemeztevékenységet mutat egy adott adatbázison:

1. Figyelje meg, mely adatbázisfájlok rendelkeznek magas MB/s olvasási vagy írási sebességgel.
2. Váltás a Legutóbbi Drága Lekérdezésekre.
3. Sorrend Fizikai olvasás/másodperc a lemezről nagy mennyiségben olvasó lekérdezések azonosítására.
4. Szűrheti vagy vizuálisan azonosíthatja a magas I/O-értékű adatbázison futó lekérdezéseket.
5. Vizsgálja meg a lekérdezések végrehajtási terveit táblabeolvasások vagy hiányzó indexek szempontjából, amelyek túlzott I/O-t okoznak.

Ez a több panelből álló elemzés összekapcsolja a tüneteket (magas lemez I/O) az okokkal (specifikus, nem hatékony lekérdezések).

9.2 Az Aktivitásfigyelő használata kapacitástervezéshez

Bár az Activity Monitor nem tárol előzményadatokat, stratégiailag felhasználható kapacitástervezési megfigyelésekhez.

9.2.1 Csúcshasználati minták azonosítása

Figyelje a szerver aktivitását a nap különböző időpontjaiban a használati minták azonosítása érdekében:

1. Nyissa meg az Aktivitásfigyelőt az ismert csúcsidőszakokban.
2. Figyelje meg a % Processor Time grafikon csúcsértékeit.
3. Jegyezze fel a várakozó feladatok maximális számát.
4. Figyelje meg a kötegelt kérések/másodperc számát csúcsidőben.
5. Dokumentálja a legforgalmasabb adatbázisokat a Folyamatok panelen.
6. Ismételje meg csúcsidőn kívül az összehasonlítás érdekében.

Ha a csúcsidőszakban a processzoridő folyamatosan meghaladja a 80%-ot, akkor közeledik a CPU-kapacitás korlátaihoz. Hasonlóképpen, a növekvő várakozási idők növekvő erőforrás-versengést jeleznek.

9.2.2 Erőforrás-trend elemzés

Bár az Aktivitásfigyelő mutatja az aktuális állapotot, időbeli rögzítéssel szúrópróbaszerűen is ellenőrizheti a trendeket:

• Készítsen képernyőképeket az Áttekintés panelről minden nap ugyanabban az időben
• Jegyezze fel az egyes grafikonok csúcsértékeit
• Hasonlítsa össze a heti adatokat a növekedési trendek azonosítása érdekében
• Figyelje az átlagos processzoridő vagy az I/O sebesség fokozatos növekedését

Ez a manuális trendmeghatározás kiegészíti a kifinomultabb monitorozási megoldásokat, és segít igazolni a kapacitásbővítést.

9.3 Teljesítmény-alapértékek dokumentálása

Az alapvető teljesítménymutatók meghatározása segít felismerni, mikor romlik a teljesítmény.

9.3.1 Alapmutatók rögzítése

Az ismerten jó teljesítmény időszakaiban dokumentálja az Aktivitásfigyelő mutatóit:

1. Az Aktivitásfigyelőt a szokásos üzleti tevékenység alatt nyissa meg (ne csúcsidőben vagy csúcsidőn kívül).
2. Rekord áttekintése panel értékei:
   • Tipikus % processzoridő-tartomány
   • Átlagos várakozó feladatok száma
   • Normál adatbázis I/O sebesség
   • Tipikus kötegelt kérések/másodperc
3. Megjegyzés: Az Erőforrás-várakozások panel kategóriái, amelyek az m értéket mutatják.ost várakozási idő.
4. Dokumentálja az aktív folyamatok számát, jellemzően a Folyamatok panelen.
5. Rögzítse a legutóbbi drága lekérdezések reprezentatív lekérdezés-végrehajtási metrikáit.

Őrizze meg ezt az alapdokumentációt későbbi felhasználás céljából, amikor teljesítményproblémákat vizsgál.

9.3.2 A jelenlegi és az alapteljesítmény összehasonlítása

Teljesítményproblémák esetén hasonlítsa össze az aktuális Aktivitásfigyelő értékeket a dokumentált alapértékekkel:

• Jelentősen magasabb a processzoridő az alapértéknél? Koncentrálj a CPU-igényes lekérdezésekre.
• A várakozási feladatok 2-3-szorosa az alapértéknek? Vizsgálja meg az erőforrásokra vonatkozó várakozási időket.
• Jelentősen magasabb az I/O? Ellenőrizze az Adatfájl I/O panelt és a költséges lekérdezéseket.
• Csúcsidőben a kötegelt kérelmek száma alacsonyabb az alapértéknél? Keressen blokkolási vagy kapcsolódási problémákat.

Ez az összehasonlítás segít azonosítani a változásokat, és ennek megfelelően összpontosítani a hibaelhárítási erőfeszítéseket.

9.4 Egyéni monitorozási munkafolyamatok létrehozása

Szisztematikus munkafolyamatokat kell kidolgozni a gyakori vizsgálati forgatókönyvekhez az alapos, megismételhető elemzés biztosítása érdekében.

9.4.1 Lépésről lépésre történő vizsgálati folyamat

Amikor a felhasználók teljesítményproblémákat jelentenek, kövesse az alábbi egységes munkafolyamatot:

1. Gyors állapotfelmérés: Nyissa meg az Aktivitásfigyelőt, és ellenőrizze az Áttekintés panel grafikonjait a nyilvánvaló rendellenességek szempontjából.
2. Blokkolás ellenőrzése: Bontsa ki a Folyamatok panelt, és szűrje ki a Nem üres elemeket a Blokkolta oszlopban.
3. Erőforrás-versengés azonosítása: Az Erőforrás-várakozások áttekintése ablaktábla várakozási idő szerint rendezve.
4. Drága lekérdezések keresése: Vizsgálja meg a legutóbbi drága lekérdezéseket CPU, végrehajtás, majd olvasás szerint rendezve.
5. Korrelált I/O minták: Költséges lekérdezések kereszthivatkozása az Adatfájl I/O ablaktábla tevékenységével.
6. Dokumentum leletek: Készítsen képernyőképeket, és rögzítse a releváns munkamenet-azonosítókat, a várakozási típusokat és a lekérdezés részleteit.
7. Mély merülést: Használja a Profiler nyomkövetéseit, a végrehajtási terv elemzését és a DMV lekérdezéseket az azonosított problémák részletes kivizsgálásához.

9.4.2 Eszkalációs kritériumok

Kritériumok meghatározása arra vonatkozóan, hogy mikor kell eszkalálni a problémákat a további vizsgálattal szemben:

• Azonnal eszkaláljon: Több mint 5 percig tartó blokkolási láncok, a processzor ideje 100%-on van >2 percig, a kritikus rendszerfolyamatok FELFÜGGESZTETT állapotot mutatnak.
• Eszkaláció elemzéssel: Ismétlődő, költséges lekérdezések, amelyek >50%-os CPU-fogyasztást igényelnek, következetesen magas I/O válaszidők >50 ms, memória-engedélyezések ismételt meghiúsulása.
• További vizsgálat: Időrary perceken belüli megoldásra vár, szuboptimális tervekkel, de elfogadható teljesítménnyel rendelkező lekérdezések, kisebb, <30 másodperces blokkolás.

10. Aktivitásfigyelő különböző módokban SQL Server változatok

Az Aktivitásfigyelő az egész világon fejlődött SQL Server verziók, minden kiadás fejlesztéseket és időnként új problémákat hozva.

10.1 Aktivitásfigyelő SQL Server 2008 és később

SQL Server 2008-ban jelent meg a modern Activity Monitor dizájn, amely ma is nagyrészt változatlan.

10.1.1 Új funkciók bevezetése SQL Server 2008

A SQL Server A 2008-as Activity Monitor újratervezése jelentős fejlesztéseket hozott:

• Grafikus irányítópult valós idejű diagramokkal az Áttekintés panelen
• Kibontható/összecsukható ablaktábla felület, amely felváltja a régi, csak rácsos nézetet
• A Legutóbbi Drága Lekérdezések panel összesített lekérdezési teljesítményadatokat jelenít meg
• Adatfájl I/O panel a fájlonkénti lemeztevékenység figyeléséhez
• Továbbfejlesztett erőforrás-várakozások panel várakozási kategorizálással
• Jobb klikkes helyi menük a folyamatműveletekhez, például a munkamenetek leállításához és a Profiler elindításához
• Konfigurálható frissítési intervallumok 1 másodperctől 1 óráig

Ezek a változások az Activity Monitort egy egyszerű folyamatlistából egy átfogó figyelőpulttá alakították át.

10.1.2 Változások ehhez képest SQL Server 2005

SQL Server A 2005-ös Activity Monitor sokkal korlátozottabb volt:

• Az Object Explorer Kezelés mappáján keresztül érhető el az eszköztár helyett
• Egyetlen rács, amelyen a folyamatlista látható az alapvető információkkal
• Nincsenek grafikus diagramok vagy több panel
• Nincsenek költséges lekérdezések vagy I/O monitorozás
• Korlátozott várakozási statisztikai információk

A 2008-as újratervezés inkább egy teljes újragondolást jelentett, mintsem fokozatos fejlesztést.

10.2 Aktivitásfigyelő SQL Server 2014/2016

SQL Server 2014-ben és 2016-ban fokozatos fejlesztéseket hajtottak végre az Activity Monitor mögöttes adatgyűjtésében, de kevés vizuális változás történt.

10.2.1 Fejlesztések és bővítések

A verziók főbb fejlesztései a következők voltak:

• Jobb teljesítmény több ezer gyorsítótárazott csomaggal rendelkező szerverek monitorozása esetén
• Továbbfejlesztett szűrési lehetőségek a Folyamatok panelen
• A várakozási statisztikák összesítésének pontosságának javítása
• Az oszlopok rendezésének és szűrésének jobb kezelése nagy eredményhalmazok esetén
• Hatékonyabb DMV lekérdezések, amelyek csökkentik a monitorozási költségeket

Az alapvető interfész konzisztens maradt SQL Server 2008, fenntartva az ismereteket az adminisztrátorok számára.

10.3 Aktivitásfigyelő SQL Server 2019/2022

Friss SQL Server A verziók folytatják az Activity Monitor fejlődését, a teljesítményre és a stabilitásra összpontosítva.

10.3.1 Legújabb funkciók és képességek

SQL Server A 2019-es és 2022-es Aktivitásfigyelő a következőket tartalmazza:

• Új várakozási típusok támogatása ezekben a verziókban
• Javított renderelési teljesítmény az SSMS-ben a WPF technológia használatával
• Nagyszámú aktív munkamenet jobb kezelése
• Fokozott kompatibilitás a felhőalapú SQL platformokkal
• Pontosabb CPU és I/O metrikák

10.3.2 Ismert problémák a legújabb verziókban

SQL Server 2019 számos Activity Monitor hibát vezetett be:

• Állandó szüneteltetett állapot: Az Aktivitásfigyelő gyakran szüneteltetett állapotba kerül, és nem folytatja a működését, különösen az SSMS 18.0-18.3 verziókban. Későbbi SSMS verziókban javítva.
• Távoli kapcsolati hibák: Bizonyos konfigurációk megakadályozzák az Activity Monitor megnyitását távoli példányokon. A megkerülő megoldások közé tartozik bizonyos nyomkövetési jelzők engedélyezése vagy újabb SSMS-buildek használata.
• Engedélyezési problémák: Az új rendszernézetek további, nem egyértelműen dokumentált jogosultságokat igényelnek, ami üres képernyőt eredményez még a SZERVER ÁLLAPOTának megtekintése esetén is.

Mindig a legújabb SSMS verziót használja, amikor a következővel dolgozik: SQL Server 2019-ben és 2022-ben, hogy elkerüljük ezeket a problémákat.

11. Gyakorlati felhasználási esetek és példák

Valós példák mutatják be, hogyan alkalmazható hatékonyan az Aktivitásfigyelő a gyakori hibaelhárítási helyzetekben.

11.1 Esettanulmány: Lassú webalkalmazás diagnosztizálása

Egy fejlesztőcsapat arról számolt be, hogy webes alkalmazásuk elfogadhatatlanul lassúvá vált, az oldalak betöltése 20-30 másodpercet vesz igénybe a szokásos 2-3 másodperc helyett.

11.1.1 Kezdeti vizsgálat az Áttekintő panellel

Nyissa meg az Aktivitásfigyelőt, és vizsgálja meg az Áttekintés panelt:

1. A % Processor Time grafikon 85-95%-os CPU-használatot mutat, ami jelentősen magasabb a normál 30-40%-os alapértéknél.
2. A várakozó feladatok száma 10-20 feladat között ingadozik, szemben a normál 0-3 alapértékkel.
3. Az adatbázis I/O mérsékelt aktivitást mutat, körülbelül 50 MB/s sebességgel.
4. A kötegelt kérések száma másodpercenként alacsonyabb a vártnál, 100/másodperc, szemben a munkaidőben jellemző 300-400/másodperc értékkel.

Ez a minta CPU-szűk keresztmetszetre utal, amely erőforrás-versengés miatt csökkenti az átviteli sebességet. A szerver keményen dolgozik, de nem dolgoz fel sok kérést.

11.1.2 A problémás lekérdezés azonosítása

Bontsa ki a Legutóbbi költséges lekérdezések panelt, és rendezze el a Végrehajtások/perc szerint:

1. A legfelső lekérdezés percenként 15 000 végrehajtást mutat.
2. Kattintson a jobb gombbal, és válassza a lehetőséget Lekérdezés szövegének szerkesztése hogy megvizsgálja a lekérdezést.
3. A lekérdezés egy egyszerű SELECT utasítás, amely egyetlen felhasználói rekordot kér le: SELECT * FROM Users WHERE UserId = @UserId.
4. Normál alkalmazáshasználat esetén ennek a lekérdezésnek nem szabad percenként 15 000-szer végrehajtódnia.

Kattintson jobb gombbal a lekérdezésre, és válassza a Végrehajtási terv megjelenítéseA terv egy táblaellenőrzést jelenít meg a Users táblában, figyelmeztetéssel a UserId oszlop hiányzó indexéről.

Szűrje a Folyamatok panelt alkalmazás szerint, hogy csak a webalkalmazás kapcsolatai jelenjenek meg. Több munkamenet esetén ugyanaz a lekérdezés ismétlődően fut.

11.1.3 Megoldás és ellenőrzés

A probléma két okból ered: a túlzott lekérdezés-végrehajtásokból és a hiányzó indexből. Megoldási lépések:

1. Hozza létre a hiányzó indexet:

   CREATE NONCLUSTERED INDEX IX_Users_UserId 
   ON Users (UserId);
   

2. Lépjen kapcsolatba a fejlesztőcsapattal a túlzott végrehajtásokról. A vizsgálat egy N+1 lekérdezési problémát tárt fel az alkalmazáskódban, ahol egy ciklus lekéri a lista minden elemének felhasználói adatait.
3. Módosítsa az alkalmazást a felhasználói keresések kötegelt összevonása egyetlen lekérdezésbe egy IN záradék vagy táblaértékű paraméter használatával.
4. A javítás ellenőrzése a telepítés utáni Tevékenységfigyelő monitorozásával. A CPU-használat 35-40%-ra csökken, a percenkénti végrehajtások száma 200-300-ra csökken, az alkalmazások válaszideje pedig visszatér a normális szintre.

11.2 Esettanulmány: Blokkolási probléma megoldása

A felhasználók arról számolnak be, hogy a rendelésbeviteli rendszer időszakosan 30-60 másodpercre lefagy, mielőtt visszatérne a normál működéshez.

11.2.1 A blokkoló lánc észlelése

Nyissa meg az Aktivitásfigyelőt az alábbi lefagyási események egyike alatt, és bontsa ki a Folyamatok panelt:

1. Sorrend Munkamenet azonosító az összes rendszerezett foglalkozás megtekintéséhez.
2. Több munkamenet értékei a következőben jelennek meg: Blokkolta oszlop, amelyek mindegyike a 73-as munkamenet-azonosítóra mutat.
3. A 73. munkamenetben az „1” érték látható. Fejblokkoló oszlop, megerősítve, hogy ez a kiváltó ok.
4. A Várakozás típusa A blokkolt munkameneteknél az LCK_M_X érték látható, ami azt jelzi, hogy kizárólagos zárolásokra várnak.
5. A Várakozási erőforrás oszlop azt mutatja, hogy a blokkolás a Rendelések táblázatban van.

11.2.2 Az ok elemzése

Kattintson a jobb gombbal a 73. munkamenet elemre, és válassza a lehetőséget Részletek parancs megtekintéséhez:

UPDATE Orders 
SET Status = 'Processing', 
    LastModified = GETDATE()
WHERE OrderId IN (SELECT OrderId FROM #TempOrders);

Ez a frissítés egy óránként futó kötegelt feldolgozási feladat része. Belépés oszlop megerősíti, hogy a munkamenet a kötegelt feldolgozási szolgáltatásfiókhoz tartozik.

A lekérdezés zárolásokat tart a Rendelések táblán, miközben több ezer megrendelést dolgoz fel. Várakozási idő A blokkolt munkamenetek száma folyamatosan növekszik, ami megerősíti, hogy ez a hosszú ideig futó művelet okozza a problémát.

11.2.3 A javítás megvalósítása

Rövid távú megoldás:

1. A 73-as munkamenet részleteinek dokumentálása, beleértve a lekérdezés szövegét és időtartamát.
2. Hagyd, hogy a frissítés természetesen befejeződjön, mivel ez jogos kötegelt feldolgozás.
3. A befejezés után ellenőrizze, hogy a blokkolt munkamenetek megszűntek-e, és a normál működés folytatódik-e.

Megvalósított hosszú távú megoldások:

1. A kötegelt feldolgozás újraütemezése csúcsidőn kívüli időszakban (hajnali 2-4 óra között, munkaidő helyett) üzemeljen.
2. A kötegelt feldolgozás módosítása a megrendelések egyszerre 100 rekordos kisebb kötegekben történő frissítése, a kötegek közötti zárolások feloldásával.
3. Adjon hozzá egy indexet az OrderId oszlopban a frissítési művelet felgyorsításához.
4. Vegye figyelembe a SNAPSHOT elkülönítését az olvasási műveletekhez a blokkolás hatásának csökkentése érdekében.

11.3 Esettanulmány: Túlzott lekérdezés-végrehajtások azonosítása

Az adatbázis-monitorozás azt mutatja, hogy a CPU-használat fokozatosan nőtt az elmúlt hónapban, de az alkalmazáskódban nem történt nyilvánvaló változás.

11.3.1 Rendellenes végrehajtási számok észlelése

Nyissa meg az Aktivitásfigyelőt, és vizsgálja meg a Legutóbbi drága lekérdezések panelt:

1. Sorrend Kivitelezések/perc látni az m-etost gyakran végrehajtott lekérdezések.
2. A leggyakoribb lekérdezés percenként 37 000 végrehajtást mutat – jóval magasabbat, mint bármely más lekérdezés.
3. Kattintson a jobb gombbal, és válassza a lehetőséget Lekérdezés szövegének szerkesztése.
4. A lekérdezés a termékkategória-információkat kéri le:

   SELECT CategoryId, CategoryName 
   FROM ProductCategories 
   WHERE CategoryId = @CategoryId;
   

5. Ennek az egyszerű lekérdezésnek gyorsnak és gyorsítótárazhatónak kellene lennie, mégis percenként több tízezer alkalommal fut le.

11.3.2 Nyomkövetés az alkalmazáskódig

A Folyamatok panelen keresse meg a lekérdezést végrehajtó munkameneteket:

1. Jegyezze fel a Alkalmazás oszlopban a „ProductCatalogService” (TermékKatalógusService) felirat látható.
2. Kattintson jobb gombbal az egyik ilyen munkamenetre, és válassza a lehetőséget Nyomkövetési folyamat SQL Server Profiler.
3. Az SQL Profiler azt mutatja, hogy a lekérdezés ismételten, gyors egymásutánban fut különböző CategoryId értékekkel.
4. A kód áttekintéséhez forduljon a ProductCatalogService fejlesztőcsapatához.

A kód áttekintése feltárja a problémát: egy friss módosítás kategóriákkal együtt kéri le a terméklistákat. Az eredményhalmazban szereplő minden egyes termékhez (gyakran több mint 1,000 termék) a kód külön adatbázishívást indít a kategóriainformációk lekéréséhez – ez egy klasszikus N+1 lekérdezési probléma.

11.3.3 Az alkalmazás optimalizálása

Végezzen el egy megfelelő javítást:

1. Az alkalmazás lekérdezésének módosítása JOIN használatához termékek és kategóriáik egyetlen adatbázishívásban történő lekéréséhez:

   SELECT p.ProductId, p.ProductName, c.CategoryId, c.CategoryName
   FROM Products p
   INNER JOIN ProductCategories c ON p.CategoryId = c.CategoryId
   WHERE p.Active = 1;
   

2. A frissített kód telepítése és figyelje az Aktivitásfigyelőt.
3. A javítás ellenőrzése: A kategória lekérdezés percenkénti végrehajtásainak száma 37 000-ről 100 alá csökken, a teljes CPU-használat pedig 40%-kal csökken.
4. Dokumentálja a tanulságot és ossza meg a fejlesztőcsapattal, hogy megelőzze a hasonló problémákat a jövőbeli kódmódosítások során.

12. Az adatbázis esetleges sérülésének észlelése

Bár az Activity Monitor nem kifejezetten az adatbázis-sérülések észlelésére szolgál, a megjelenítésében megjelenő bizonyos minták olyan mögöttes sérülési problémákra utalhatnak, amelyek további vizsgálatot indokolnak.

12.1 Az adatbázis-sérülés lehetséges tünetei

Ha az adatbázis sérült és ahhoz hozzáférnek, időnként a következőket láthatja:

1. A Folyamatok panelen:

• A munkamenetek FELFÜGGESZTETT állapotban ragadtak szokatlan várakozási típusokkal
• Hibaállapotokat mutató folyamatok
• A lekérdezések ismételten sikertelenek

2. Az Erőforrás-várakozások panelen:

• Szokatlan I/O-hoz kapcsolódó várakozási típusok, amelyek lemezproblémákra utalhatnak (bár ez valószínűbb hardverproblémákra, mint logikai sérülésre utal)

3. A Legutóbbi Drága Lekérdezések részben:

• Rendellenesen magas fizikai olvasási arányú lekérdezések, ha ismételten sérült oldalakat próbálnak olvasni

12.2 További ellenőrzés a DBCC CHECKDB segítségével

Amikor az Activity Monitor olyan tüneteket jelenít meg, amelyek potenciális sérülésre utalnak, azonnal futtassa a DBCC CHECKDB parancsot az adatbázis integritásának ellenőrzéséhez. Ez a parancs átvizsgálja az összes adatbázisoldalt, érvényesíti az ellenőrzőösszegeket, és logikai konzisztenciahibákat keres.

Ha többet szeretne megtudni arról, hogyan használható a DBCC CHECKDB az adatbázis-sérülések ellenőrzésére és javítására, tekintse meg a következőt: átfogó DBCC CHECKDB útmutató.

12.3 Javítás professzionális eszközökkel

Ha a DBCC CHECKDB megerősíti az adatbázis sérülését, több lehetősége is van a javításra:

• Az előnyben részesített megközelítés egy ismert, jó biztonsági mentésből való visszaállítás. Lásd: Átfogó útmutatónk a biztonsági mentésről és visszaállításról SQL Server adatbázisok.
• Kisebb sérülések esetén a DBCC CHECKDB és a REPAIR_REBUILD parancs segíthet megoldani a problémákat.
• A friss biztonsági mentések nélküli kritikus adatbázisok esetében a szakemberek SQL helyreállító szoftver és a szolgáltatások gyakran képesek olyan adatokat helyreállítani, amelyeket a beépített javítási lehetőségek nem.

13. Következtetés

SQL Server Az Activity Monitor felbecsülhetetlen értékű eszköz az adatbázis-adminisztrátorok számára, amely azonnali betekintést nyújt a szerver teljesítményébe, és segít a problémák gyors és hatékony diagnosztizálásában.

13.1 A kulcsfontosságú pontok összefoglalása

Ebben az útmutatóban azt vizsgáltuk, hogy az Activity Monitor hogyan segít megérteni és elhárítani a problémákat SQL Server teljesítmény:

• Az Activity Monitor valós idejű betekintést nyújt a folyamatokba, várakozásokba, lekérdezésekbe és I/O-ba egy rendezett, grafikus felületen keresztül.
• Az öt panel – Áttekintés, Folyamatok, Erőforrás-várakozások, Adatfájl I/O és Legutóbbi költséges lekérdezések – mindegyike egyedi perspektívát kínál a szerver tevékenységére.
• A gyakori hibaelhárítási forgatókönyvek, mint például a túlzott lekérdezés-végrehajtás, a blokkoló láncok és a magas CPU-használat, kezelhetővé válnak a szisztematikus Activity Monitor vizsgálattal.
• Bár hatékony, az Activity Monitornak vannak korlátai, beleértve a korábbi adatok hiányát, a várakozási típusok csoportosítását és a monitorozási terhelést, amelyek befolyásolják az alkalmazását.cabalkalmasság.
• Az Activity Monitor DMV-lekérdezésekkel, sp_WhoIsActive, Extended Events és potenciálisan harmadik féltől származó eszközökkel való kiegészítése átfogó monitorozási stratégiát hoz létre.
• A frissítési időközökre vonatkozó ajánlott gyakorlatok betartása, az Aktivitásfigyelő bezárása használaton kívül, valamint több panel összekapcsolása a korreláció érdekében maximalizálja az értékét, miközben minimalizálja a hatását.

13.2 Aktivitásfigyelő az eszköztár részeként

Az Activity Monitornak az elsődleges válaszadó eszközként kell szolgálnia a teljesítményvizsgálatok során, nem pedig az egyetlen eszközként. Erőssége abban rejlik, hogy azonnali láthatóságot biztosít az aktív hibaelhárítás során, segítve gyorsan meghatározni, hogy az adatbázis a szűk keresztmetszet, és azonosítani, hogy mely konkrét aspektusok igényelnek alaposabb vizsgálatot.

Gondolj az Aktivitásfigyelőre úgy, mint egy autó műszerfalára – azonnal jelzi, ha valami nincs rendben, és segít azonosítani a probléma általános helyét. Ahogy az autó műszerfala sem mondja meg pontosan, hogy miért világított a motorhiba jelzőfény, az Aktivitásfigyelő is a problémákra irányít rá anélkül, hogy mindig feltárná azok teljes okát. Ez a mélyebb elemzés további eszközöket és szakértelmet igényel.

Integrálja az Activity Monitort egy szélesebb eszközkészletbe, amely magában foglalja a végrehajtási terv elemzését, a várakozási statisztikák nyomon követését, a korábbi monitorozási megoldásokat és a teljesítményre vonatkozó ajánlott gyakorlatokat. Használja megfelelő indexelési stratégiákkal, lekérdezésoptimalizálási technikákkal és kapacitástervezéssel együtt.

13.3 A tanulási folyamat folytatása

Az Activity Monitor elsajátítása csak egy lépés a hatékony adatbázis-adminisztrátorrá válás felé. Folytassa készségeinek fejlesztését az alábbiakkal:

• A végrehajtási tervek értelmezésének megtanulása és a nem hatékony műveletek azonosítása
• Egyetértési SQL Server várakozási statisztikák és azok következményei
• Indextervezési és optimalizálási technikák tanulmányozása
• Feltárása SQL Serverarchitektúrája és a lekérdezések feldolgozásának módja
• Szisztematikus hibaelhárítási módszerek gyakorlása
• Tapasztalatépítés kibővített eseményekkel a részletes nyomkövetés érdekében
• A tranzakciók elkülönítési szintjeinek és azok teljesítményre gyakorolt ​​hatásának megértése

Minden egyes, az Aktivitásfigyelővel végzett teljesítményvizsgálat valami újat tanít arról, hogyan SQL Server működik, és hogyan működnek együtt az alkalmazások az adatbázisokkal. Dokumentálja eredményeit, ossza meg tudását kollégáival, és építsen egy könyvtáratrarmegoldások y gyakori problémákra.

13.4 További források

Bővítsd tudásodat ezekkel az értékes forrásokkal:

• Nyissa meg az Activity Monitort SQL Server Menedzsment Stúdió (SSMS) : Hivatalos SQL Server dokumentáció az Aktivitásfigyelő megnyitásáról SQL Server Management Stúdió (SSMS).
• Activity Monitor : Hivatalos SQL Server dokumentum az Aktivitásfigyelő használatáról.

14. Gyakran Ismételt Kérdések (GYIK)

K: Mi az SQL Server ActivityMonitor?

A: SQL Server Az Aktivitásfigyelő egy beépített eszköz a SQL Server Management Studio, amely valós idejű információkat jelenít meg a gépen futó folyamatokról SQL Server példányokat és azok hatását a szerver erőforrásaira. Egy grafikus irányítópultot biztosít, amely öt panellel mutatja a szerver tevékenységének különböző aspektusait, beleértve a processzorhasználatot, a várakozó feladatokat, az I/O sebességeket, az aktív munkameneteket és a költséges lekérdezéseket.

K: Hogyan nyithatom meg az Aktivitásfigyelőt az SSMS-ben?

V: Az Aktivitásfigyelőt négyféleképpen nyithatja meg: (1) Kattintson az Aktivitásfigyelő ikonra az SSMS eszköztáron, (2) Kattintson jobb gombbal a SQL Server példány neve az Objektumkezelőben, és válassza ki Activity Monitor, (3) Nyomja meg Ctrl + más + A, vagy (4) Konfigurálja az SSMS-t úgy, hogy automatikusan elinduljon a következőn keresztül: Eszközök -> Opciók -> Környezet -> Starcső.

K: Milyen engedélyekre van szükségem az Aktivitásfigyelő használatához?

V: Szükséged van rá SZERVER ÁLLAPOT MEGTEKINTÉSE engedélyt a látásraost Aktivitásfigyelő információk. Az Adatfájl I/O panelhez a következőkre is szüksége lesz: LÉTREHOZ DATABÁZIS, BÁRMELY ADATBÁZIS MÓDOSÍTÁSAvagy BÁRMELY DEFINÍCIÓ MEGTEKINTÉSE engedélyek. Ezen engedélyek nélkül előfordulhat, hogy az Aktivitásfigyelő megnyílik, de üres paneleket jelenít meg.

K: Miért van szüneteltetve vagy nem működik az Aktivitásfigyelőm?

A: Az Aktivitásfigyelő általában jogosultsági problémák, elavult SSMS-verziók vagy letiltott távoli kapcsolatok miatt szünetel. A megoldás: (1) Frissítsen a legújabb SSMS-verzióra, (2) Ellenőrizze, hogy rendelkezik-e SZERVERÁLLAPOT MEGTEKINTÉSE engedéllyel, (3) Ellenőrizze, hogy a távoli kapcsolatok engedélyezve vannak-e a(z) SQL Server például (4) Restart SSMS, és (5) Próbáljon meg Windows hitelesítéssel csatlakozni SQL hitelesítés helyett, ha alkalmazhatócabazokat.

K: Mi a különbség az Aktivitásfigyelő és az sp_WhoIsActive között?

A: Az Activity Monitor egy grafikus eszköz, amely az SSMS-be van építve, és szervezett paneleket biztosít a különböző monitorozási szempontokhoz. Az sp_WhoIsActive egy ingyenes, közösség által létrehozott tárolt eljárás, amely részletes munkamenet-információkat ad vissza egyetlen eredményhalmazban, konkrétabb várakozási típusokkal, blokkolási részletekkel és testreszabási lehetőségekkel, mint az Activity Monitor. Az Activity Monitor jobb a vizuális feltáráshoz, míg az sp_WhoIsActive a szkriptelt monitorozásban jeleskedik, és részletesebb információkat nyújt.

K: Befolyásolja-e az Aktivitásfigyelő a szerver teljesítményét?

V: Igen, az Activity Monitor mérhető terheléssel jár, mivel minden frissítési intervallumban lekérdezi a rendszer DMV-it. A hatás az alacsonyabb frissítési gyakorisággal növekszik – a Microsoft figyelmeztet, hogy a 10 másodpercnél rövidebb időközök befolyásolhatják a szerver teljesítményét. Mindig zárja be az Activity Monitort, ha nem használja aktívan, és vegye figyelembe a 30-60 másodperces frissítési intervallumokat a nagy terhelés alatt lévő éles szervereken.

K: Lekérhetek Activity Monitor adatokat T-SQL használatával?

V: Igen, az Activity Monitor lekérdezi a rendszerdinamikai felügyeleti nézeteket, mint például a sys.dm_exec_requests, sys.dm_exec_sessions, sys.dm_os_wait_stats és sys.dm_exec_query_stats. Ezeket a DMV-ket közvetlenül lekérdezheti T-SQL használatával, hogy programozottan lekérje az egyenértékű információkat, lehetővé téve az egyéni monitorozási szkriptek és az automatizált adatgyűjtés használatát.

K: Mi az alapértelmezett frissítési intervallum?

V: Az alapértelmezett frissítési időköz 10 másodperc. Ezt úgy módosíthatja, hogy jobb gombbal kattint az Áttekintés panel bármely pontjára, majd a Frissítési intervallum, és válasszon az előre definiált beállítások közül: 1 másodperc, 5 másodperc, 10 másodperc, 30 másodperc, 1 perc vagy 1 óra. Az alacsonyabb intervallumok valós idejűbb nézetet biztosítanak, de növelik a monitorozási terhelést.

K: Hogyan tudom automatikusan megnyitni az Aktivitásfigyelőt az SSMS-en?tarkos?

A: Az automatikus indítás konfigurálása az SSMS beállításain keresztül: Navigáljon a következőhöz: Eszközök -> Opciók -> Környezet -> Starcső, Majd válassza ki Objektumkezelő és Tevékenységfigyelő megnyitása tól A starcső legördülő menü. Az Aktivitásfigyelő automatikusan megnyílik minden alkalommal, amikor csatlakozik egy szerverhez az SSMS-ben.

K: Milyen korlátai vannak az Aktivitásfigyelőnek?

V: A főbb korlátozások a következők: (1) Nincsenek historikus adattárolási vagy trendkövetési lehetőségek, (2) A várakozási típusok kategóriákba vannak csoportosítva, ahelyett, hogy konkrétan megjelennének, (3) Egyes várakozási típusok, mint például a CXPACKET, esetleg nem jelennek meg, (4) Az adott időpontra vonatkozó pillanatképek nem feltétlenül jelennek meg, (5) A monitorozási terhelés hatással lehet a forgalmas szerverekre, (6) Nincs riasztási mechanizmus a proaktív monitorozáshoz, és (7) Nem lehet több szerver között összesíteni az adatokat SQL Server példányok. Ezen igények kielégítésére egészítse ki az Aktivitásfigyelőt kiterjesztett eseményekkel, adatgyűjtő készletekkel vagy harmadik féltől származó figyelőeszközökkel.

---

A szerzőről

Yuan Sheng több mint 10 éves tapasztalattal rendelkező vezető adatbázis-adminisztrátor (DBA) SQL Server környezetekben és vállalati adatbázis-kezelésben. Több száz adatbázis-helyreállítási forgatókönyvet oldott meg sikeresen pénzügyi szolgáltatások, egészségügyi ellátás és gyártási szervezetek számára.

Yuan specializálódott SQL Server adatbázis-helyreállítás, magas rendelkezésre állású megoldások és teljesítményoptimalizálás. Kiterjedt gyakorlati tapasztalata magában foglalja a több terabájtos adatbázisok kezelését, az Always On Availability Groups megvalósítását, valamint az automatizált biztonsági mentési és helyreállítási stratégiák kidolgozását kritikus fontosságú üzleti rendszerekhez.

Yuan műszaki szakértelmének és gyakorlatias megközelítésének köszönhetően átfogó útmutatók készítésére összpontosít, amelyek segítik az adatbázis-adminisztrátorokat és az informatikai szakembereket a komplex problémák megoldásában SQL Server hatékonyan kihívásokat intéz. Folyamatosan naprakész a legújabb információkkal. SQL Server kiadásait és a Microsoft fejlődő adatbázis-technológiáit, rendszeresen tesztelve a helyreállítási forgatókönyveket annak érdekében, hogy ajánlásai a valós legjobb gyakorlatokat tükrözzék.

Kérdései vannak a SQL Server helyreállításra vagy további adatbázis-hibaelhárítási útmutatásra van szüksége? Yuan örömmel fogadja visszajelzéseket és javaslatokat ezen technikai erőforrások fejlesztéséért.