Ez a Sybase szoftverterméke, amely az SQL Serverrel együtt működik, és grafikus formában számos információt nyújt a szerver teljesítményéről. Ez az információ rendkívül hasznos a teljesítménycsökkenés okainak elemzéséhez.

A 11.0.1-es verzió számos új fontos funkcióval rendelkezik, amelyek jelentősen megkülönböztetik az új verziót az összes korábbi verziótól. A 11.0.1 az SQL Server bármely verziójával működik a 4.9.2-től a System 11-ig.

Az adatbázis-objektumok használati mintáiról és a kiszolgáló hálózattal való interakciójáról azonban néhány legérdekesebb információ csak az SQL Server System 10 és System 11 figyelésekor érhető el. Természetesen az elnevezett cache pufferek teljesítményére vonatkozó adatok csak az SQL Server System 11 teljesítményének figyelésekor biztosított.

A korábbi verziókkal való kompatibilitás érdekében a 11.0.1 támogatja azt a módot is, amely a szerver teljesítményére vonatkozó statisztikai adatok fájlokba történő kiadására szolgál, amelyek későbbi összehasonlításra és elemzésre használhatók. Ez a funkció nagyon hasznos a gyakorlatban, de használata megnehezíti a telepítési folyamatot.

két összetevőből áll: egy szervermodulból, amely ugyanazon a gépen fut az SQL Serverrel, hogy hozzáférést biztosítson a kiszolgáló megosztott memóriaterületéhez, és egy kliens modulból, amely bármely számítógépen futhat. A kliens modul fő feladata a szerver modul által felhalmozott információk beolvasása és grafikus formában történő bemutatása a felhasználó számára.

Indításkor meg kell szakítania a dbcc memusage paranccsal végrehajtott kiszolgálómemória-ellenőrzést, mivel ez a parancs jelentősen lelassítja a kiszolgálót. Ehhez az sqlmon (kliens modul) indításakor meg kell adni a – nomem paramétert.

Az alapértelmezett konfiguráció lehetővé teszi akár öt ügyfélmodul egyidejű csatlakoztatását egy szervermodulhoz. Más szóval, egy kiszolgálómodul vagy öt ügyfélmodulhoz csatlakoztatható, mindegyik kliensen egy ablakkal, vagy egy kliens öt nyitott ablakkal.

Az egyidejűleg megnyíló ügyfélablakok maximális száma a szervermodul indításakor kerül beállításra.

Tehát ahhoz, hogy 20 ablakot támogasson a parancsfájlban a szervermodul indításához, meg kell adnia az n2 0 paramétert. Ebben az esetben meg kell változtatnia a szerver megosztott memóriaterületének kezdetének címét a segítségével a buildmaster parancs és néhány egyéb művelet. Ezeket a műveleteket soha nem szabad végrehajtani az SQL Server futása közben. (A támogatott egyidejű kliensek számának bővítésének folyamatával kapcsolatos részletekért lásd a Kiszolgáló kiegészítési kézikönyvet.)

van néhány hátránya. Például egy oszlopdiagram, amely a folyamatban lévő I/O műveletek számát és a szervereszközök egyéb teljesítményjellemzőit mutatja, egyszerre csak korlátozott számú eszközről tud adatokat jelenteni.

Ez kényelmetlen, ha nagy szervert figyelünk nagyszámú szervereszközzel. Ezen túlmenően a felhasználó nem választhat olyan eszközöket, amelyekről a táblázatban szerepelni fog az információ, és nem válthat a különböző eszközkészletek között.

A diagrammal egyidejűleg a képernyőn megjelenő szöveges táblázat tartalmazza az összes szervereszköz listáját, de csak az egyes I/O műveletek teljes számát tartalmazza. Ez különösen nehéz, ha olyan nagy szerverrel dolgozik, amely számos kiszolgálóeszközzel támogatja a felhasználói adatbázis-szegmenseket a teljesítményének javítása érdekében. Ebben az esetben az összes létező szegmens működésének elemzése lehetetlen.

Ezenkívül nem teszi lehetővé, hogy a teljesítménymutatók változásának dinamikája hosszú ideig megjelenjen a képernyőn.

60 egymást követő teljesítménymérési intervallum adatait képes megjeleníteni. Az egyes intervallumok választott időtartamától függően az ilyen statisztikák meglehetősen hosszú időtartamot fedhetnek le. Ez a technika azonban nem teszi lehetővé a jelenlegi adatok összehasonlítását egy hónappal vagy egy évvel ezelőtti mutatókkal.

Természetesen a programablak képei kinyomtathatók a nyomtatóra, de ekkor fájlkészleteket vagy nyomathegyeket kell tárolnia a szerver jövőbeli teljesítményének értékeléséhez. A gyakorlatban a szerveradminisztrátornak gyakran újra meg kell vizsgálnia a vállalat üzleti ciklusának különböző időpontjaiban gyűjtött adatokat, valamint az egymást követő üzleti ciklusok hasonló időszakaira vonatkozó információkat, hogy betekintést nyerjen a szerver tényleges teljesítményébe.

Mivel az indítás a szerver némi lassulását eredményezi, a mérések megkezdése előtt meg kell határozni ennek a lassulásnak a mértékét egy adott hardver és szoftver platformon. A mérés jó módja egy szabványos teszttranzakció-készlet futtatása.

Mindkettő használható, ha jelen van vagy nincs a szervergépen. Ha nincsenek kliens modulok, a program szerver modulja továbbra is működik, és külön paranccsal le kell állítani.

lehetővé teszi több különböző grafikus ablak megjelenítését, amelyek mindegyike a szerver működésének egy bizonyos aspektusáról tartalmaz információkat.

Főablak
Ez tartalmazza a program által támogatott ablakok listáját. Ha az sglmon indításakor a kliens modul, a – nomem paraméter nem lett megadva, akkor ez az ablak egy kördiagramot is megjelenít a szerver gép memóriahasználatáról.

Gyorsítótár pufferek
Ez az ablak az eljárás- és adatgyorsítótár pufferek működését jellemző grafikonokat jeleníti meg. Az adatgyorsítótár pufferében lévő fizikai és logikai I/O műveletek számának szabályozásával a felhasználó meghatározhatja, hogy az adatlapokhoz való hozzáférés mekkora részét fogja végrehajtani a szerver a pufferben már lévő oldalak használatával. Ezek az adatpufferre és az eljárási pufferre vonatkozó statisztikák lehetővé teszik számunkra, hogy meghatározzuk a kiszolgáló gyorsítótár pufferei által igényelt teljes memóriamennyiséget, valamint az adat- és eljárás-gyorsítótár pufferei közötti arányt.

Adatpuffer gyorsítótár, csak SQL Server System 11 (Data Cach)
Az ablak jelenti a fizikai és logikai I/O műveletek számát a kiszolgálón konfigurált egyes megnevezett gyorsítótárpufferekhez.

Lemez I/O
Itt grafikonokat és összefoglaló táblázatokat találhat a lemezelérések aktuális és teljes számáról. Segítenek optimalizálni az I/O terheléselosztást a meglévő szervereszközök között. A kimeneti információk elemzésekor célszerű a szabványos sémát használni a kiszolgálóeszközök nevének kiválasztásához a fizikai lemezek megfelelő szakaszainak neve alapján, mivel a kiszolgálóeszközökkel való átváltási árfolyam figyelésekor tudnia kell, melyik lemezvezérlő ezeknek az eszközöknek mindegyike csatlakoztatva van.

Működés a hálózattal, csak az SQL Server System 10 és 11 (hálózati tevékenység) esetén
Az ablak statisztikai információkat közöl a hálózati bemenetről és kimenetről - csomagméretek, forgalom mennyisége stb.

Objektumokhoz való hozzáférés blokkolása, csak az SQL Server System 10 és 11 esetén (Object Lock Status)
Ez információkat jelenít meg az adattáblázat hozzáférési zárairól, beleértve a használt zárolások típusának részletes lebontását, a zárakat tartó folyamatok nevét stb.

Objektumoldal I/O, csak SQL Server System 10 és 11 (Object Page I/O)
Az ablak az egyik szerveradattábla I/O oldalainak intenzitásával kapcsolatos információkat tartalmaz. A leggyakrabban használt szervertáblák listájának összeállításakor ügyeljen a hatékonyságra. Az ilyen típusú információkat az sp_sysmon nem adja vissza.

Teljesítmény összefoglaló
Ez átfogó képet nyújt az SQL Server teljesítményéről – a felhasznált CPU-idő százalékáról, a másodpercenként feldolgozott tranzakciók számáról, a hálózati forgalom mennyiségéről, a lemez I/O-ról és a zárhasználatról.

Teljesítménytrend
Az ablak a Teljesítményösszegzés ablakban megjelenített kiszolgáló teljesítménymutatóinak folyamatos grafikonját ábrázolja az idő függvényében.

Szerver folyamattevékenység (folyamataktivitás)
Az ablak lehetővé teszi egy vagy több szerverfolyamat kiválasztását, valamint az egyes folyamatok CPU-használatának és I/O-köteteinek figyelését.

A folyamat részletei
Az ablak részletes információkat tartalmaz a kiválasztott szerverfolyamatról.

Folyamatlista
Az ablak az összes jelenleg elérhető szerverfolyamat listáját tartalmazza állapotuk jelzésével. Nagyon hasonló az sp_who szerver parancs kiadásához.

A Process Lock Activity használata
Az ablak a kiválasztott szerverfolyamat által használt zárolásokról nyújt információkat.

Tárolt eljárási tevékenység használata
Az ablak a tárolt eljárások végrehajtásáról és az egyes eljárások futási idejéről tartalmaz információkat.

Tranzakciós tevékenység
Az ablakban láthat egy oszlopdiagramot, amely a feldolgozás alatt álló tranzakciók számát mutatja, különböző tranzakciótípusok szerinti bontásban. Megnézheti például, hogy a tranzakciók mely része hajtható végre a frissítés helyén mechanizmussal.

2006.12.26. Kevin Kline

Mi az utolsó kérdés, amelyet egy DBA szeretne feltenni? Valószínűleg a felhasználó üzenete az alkalmazás leromlásával kapcsolatban, vagy kérdés, hogy mi történt az adatbázissal. Mindent félre kell tennünk, és „vész üzemmódba” kell lépnünk, vajon meddig fog ez tartani. Mivel az adatbázis-adminisztrátor egyik fő feladata az ipari adatbázisok magas színvonalú működésének biztosítása, már csak a probléma mielőbbi elhárítása van hátra. A hiba okának kiderítésére általában nincs idő.

Nincs több rohanó munka – csak szisztematikus megfigyelés

De ez az egyetlen dolog, amit meg lehet tenni? Lehetőség van proaktív teljesítményfigyelésre, egy egyszerű felügyeleti eljárásra, amely rendszer alapállapotokat, benchmarkingot és folyamatos monitorozást használ. Ebben a cikkben arról fogok beszélni, hogyan használhatjuk a proaktív megfigyelést, és hogyan hozhatunk létre ingyenes megfigyelőrendszert a Windows System Monitor segítségével.

Proaktív felügyelet

A proaktív teljesítményfigyelés egy egyszerű rendszer, amely segít megoldani a problémákat, mielőtt azok kritikussá válnának. Vannak, akik valószínűleg már használják a kivételfigyelést, ahol olyan automatizált folyamatokat hoznak létre, amelyek csak az anomáliákat veszik észre, de nem adnak mélyreható információkat vagy nem képesek megelőzni a problémákat. A proaktív teljesítményfigyelés viszont mindenféle információval látja el a felhasználót a munkakörnyezetről és az alkalmazásokról, rövid és hosszú távon egyaránt. Adatbázis-teljesítményszámlálókat vesznek fel, benchmark mérőszámokat hoznak létre, és aktív megfigyelést tartanak fenn.

Ahogy a neve is sugallja, a proaktív teljesítményfigyeléshez cselekvésre van szükség. Egy kis időbe telik a telepítés, és némi időbe telik az adatbázisok és alkalmazások működésének megértése. Ahhoz, hogy a proaktív teljesítményfigyelés hatékony legyen, az üzeneteket felül kell vizsgálni, hogy az összegyűjtött gazdag adatokat ki lehessen használni.

Alapparaméterek, standard, monitor

Kezdjük néhány fogalom meghatározásával. Alapparaméterek (alapérték) olyan paraméterek halmaza, amelyek a kiszolgáló és az alkalmazás normál körülmények közötti viselkedését tükrözik. Az alapparamétereket több azonos körülmények között végzett mérés eredményei alapján átlagokként kaptuk meg; viszonyítási alapok.

Benchmark megmutatja a rendszer teljesítményét egy bizonyos szerverterhelési szinten, amely lehetővé teszi egy ipari szerver teljesítményének összehasonlítását ezen a szinten, és meghatározza a szerver teljesítményét, mennyivel magasabb vagy alacsonyabb a normálnál (vagyis amikor a szerver rosszul teljesít). Az alapparaméterekhez hasonlóan a benchmark értékeket is ellenőrzött környezetben veszik fel, és a kulcsértékeket előre meghatározott mutatókhoz viszonyítva határozzák meg. Ha látnia kell, hogyan viselkedik a szerver és az alkalmazás több szinten vagy típusú terhelés mellett, akkor általában több referenciaértéket kap (az alapparaméterekhez képest)

Monitoring- ez a szerver tervezett valós idejű monitorozása előre meghatározott feltételek mellett (további vizsgálathoz vagy figyelmeztetésekhez meghatározott feltételkészletek). Például, ha meg szeretné tudni, hogy mennyi ideig tart egy kritikus üzleti alkalmazás sikeres futtatása, mennyi ideig tart a biztonsági mentés, vagy mikor értek el bizonyos teljesítménymérföldköveket, akkor ezeket a konkrét eseményeket figyeli a rendszer.

Most térjünk át a proaktív megfigyelésre. Használhat harmadik féltől származó termékeket vagy ingyenes megoldást, amely a System Monitort használja. A harmadik féltől származó megoldások leegyszerűsíthetik a proaktív megfigyelés beállításának folyamatát, és más funkciókkal is rendelkezhetnek, mint egy ingyenes, beépített megoldás. Mielőtt azonban elkezdenénk, megmutatom, hogyan kezdje el a proaktív megfigyelést a System Monitor használatával.

1. lépés: Határozza meg a teljesítmény alapértékeit.

A proaktív felügyeleti mód biztosításának első lépésében az adatbázis-kiszolgáló működéséhez szükséges alapvető paraméterek készlete kerül kialakításra. Ez az aggregátum jelzi a szerver teljesítményét normál körülmények között, segít dokumentálni és megérteni minden jelentős háttérfolyamatot, valamint segít azonosítani a beavatkozást nem igénylő helyzeteket, hogy a jövőben figyelmen kívül hagyható legyen. Más szóval, az adatbázis-adminisztrátorok megadhatnak olyan beállításokat, amelyek figyelmen kívül hagyják a rendszerüzeneteket, mivel ellenkező esetben nagyszámú hamis értesítés jön létre.

A működés minőségének egyértelmű bemutatása érdekében a legjobb alapvonalak néhány grafikont (ideális esetben egyet) használnak, így egy pillantással láthatja, hogyan teljesít a szerver. Az alapvető paraméterek meghatározása után a következőket kell tennie. Először válassza ki a teljesítményadatok rendszernaplóba való mentését vagy valós időben történő megjelenítését. Ideális, ha mindkettő megvan: a naplók lehetővé teszik, hogy bármikor visszatekintsen a leolvasásokra, és elemezze, milyen volt a teljesítmény, amikor nem közvetlenül figyelte a rendszert. A valós idejű megfigyelés nem foglal helyet a lemezen vagy a szerver erőforrásaiban, de 100 százalékos figyelmet igényel a rendszerre. Másodszor, meg kell határoznia a felügyelet végrehajtásának időtartamát, figyelembe véve az adatgyűjtés és az adat I/O műveletek teljesítményköltségeit, és meg kell becsülnie a szükséges terület költségét. Minél hosszabb az intervallum, annál nagyobb a valószínűsége annak, hogy a kívánt teljesítményadatokat nem kapjuk meg. Végül válassza a helyi vagy távfelügyeletet. A helyi megfigyelés, amelyben a megfigyelési folyamat felügyelt szervert használ, CPU- és lemezráfordítást ad a szerverhez. A külön szervert használó távfelügyelet kiküszöbölheti ezeket a problémákat, de nagymértékben megnöveli a hálózat leterheltségét.

Felsorolja azokat a System Monitor mérőszámokat vagy számlálókat, amelyek használatát javasoljuk az alapvonal meghatározásához. Nem tudom megmondani, hogy egy adott alkalmazás kontextusában mi a „helyes” érték, mivel rendszerenként változik. Használja a különböző alapvonalak átlagát a normál alapvonali teljesítmény beállításához, és jelezze, hogy ez a megfelelő beállítás a használt rendszer számára.

Alapbeállítások meghatározása a System Monitor segítségével

Most az alapvető paraméterek összegyűjtése céljából hívjuk a System Monitort. Nyissuk meg a Vezérlőpult, Felügyeleti eszközök, Teljesítmény menüpontot. Kattintson duplán a Teljesítménynaplók és riasztások elemre a bal oldali ablaktáblában. Kattintson a jobb gombbal a Számlálónaplók elemre, és válassza az Új naplóbeállítások lehetőséget. Adja meg a grafikon nevét, majd kattintson az OK gombra. A Számlálók kiválasztása párbeszédpanelen válassza ki az első számlálót, majd kattintson a Hozzáadás gombra. Ismételje meg ezeket a lépéseket, amíg az összes számlálót hozzá nem adja, majd kattintson a Bezárás gombra.

A kezdéshez próbálja meg az alapértelmezett 15 másodperces intervallumot. Vagy válasszon ki egy másik intervallumot a Tulajdonságok gombra kattintva (vagy használja a Ctrl + Q billentyűparancsot), majd adjon meg egy Minta feliratú értéket automatikusan _ másodpercenként. A hosszabb időközök kevesebb helyet foglalnak el, de kevésbé részletes adatokat szolgáltatnak.

Válassza ki a Naplófájlok táblát, és határozza meg az adatok tárolási helyét. Az adatokat később megtekintheti a Naplófájl adatok megtekintése nézetben. A Rendszerfigyelő úgy fog kinézni, ahogy az 1. ábra mutatja, mikor gyűjti az alapszintű teljesítményadatokat. Látható, hogy sok mérő egyidejű figyelésével nagyon sok adat gyűjthető, ezért érdemes körültekintően kiválasztani a fővezeték mérőóráit.

2. lépés: Referenciaértékek beállítása

Miután a kiszolgáló teljesítményének alapértéke létrejött, megkezdheti a referenciaértékek beállítását, amelyek megkönnyítik a szerver teljesítményének megértését, ha több előre meghatározott helyzetben fut.

A szabványok esetében ugyanaz a felügyeleti mód használatos, mint az alapvető paraméterek meghatározásánál. Használhatja saját megoldását vagy az általános iparági eszközök egyikét, például a TPC-C-t vagy az SAP-t, de a legjobb eredményeket a benchmark értékek kiszámításához olyan általános egyéni szkriptek fejlesztésével érheti el, amelyek egy adott adatbázis-kiszolgáló és alkalmazásai használatára vannak konfigurálva. .

Létrehozhatja saját szkriptjét a T-SQL parancsfájlcsomag, az osql segédprogramok vagy a Query Analyzer, SQL Profiler és System Monitor segítségével. A terhelési teszt szkriptek T-SQL-ben történő fejlesztése általában több napot vesz igénybe. Még több időre lehet szükség a terhelési teszt végrehajtási adatainak összegyűjtéséhez és a kapott adatok elemzéséhez.

Miután megállapította a szerver teljesítményének alapvonalát előre meghatározott munkaterhelés mellett, tudni fogja, mire számíthat a rendszertől. Használja a referenciaértékek megszerzéséhez gyűjtött adatokat a rutin ellenőrzés alapjául. Például a szerverről azt találták, hogy másodpercenként akár 249 tranzakciót is képes lebonyolítani, mielőtt lassulna. Ebben az esetben alacsony prioritású értesítést állíthat be, ha a szerver eléri a körülbelül 200 TPS-t, és magas prioritású értesítést, ha a szerver eléri a 235 TPS-t. Ez a módszer lehetővé teszi a rendszergazdának, hogy tájékozódjon a szerverrel kapcsolatos lehetséges problémákról, és megtegye a szükséges intézkedéseket, mielőtt a felhasználók bármit is észrevennének. És nincsenek kritikus helyzetek. Most már lehetséges.

3. lépés: Ütemezett megfigyelés

A proaktív monitoring rendszer talán legfontosabb eleme a tervezett monitoring. Enélkül nem figyelheti az adatbázis teljesítményét, és nem észlelheti a teljesítményproblémákat.

Létrehozhat egy olcsó SQL Server megfigyelő eszközt az SQL Server Agent és a System Monitor kombinációjával. Az SQL Server Agent lehetővé teszi annak meghatározását, hogy melyik esemény okozta a hiba megjelenését a monitoron, meghatározza, hogy ki kapjon értesítést az eseményekről, és automatikusan értesítést küldjön hibaesemény esetén.

Az SQL Server Agent telepítése időigényes és bonyolult lehet, ezért további információért olvassa el az Alerts in SQL Server részt. Online könyvek (BOL). Az SQL Server Agent általában figyeli az adatbázis-kiszolgáló hibaüzeneteit, és nem figyeli a végrehajtást.

A kiszolgáló teljesítményének figyeléséhez használja a System Monitort az aktuális számlálók figyeléséhez (állítsa be a lekérdezési gyakoriságot 15 percen belülre).

Memória-oldal/mp

Hálózati interfész-Bájtok összesen/sec

Fizikai lemez-lemez átvitel/mp

Processzor-% Processzoridő

SQLServer: Hozzáférési módszerek – Teljes vizsgálat/mp

SQLServer: pufferkezelő-puffer gyorsítótár találati aránya

SQLServer:Databases Application Database-Transactions/sec

SQLServer: Általános statisztika-Felhasználói kapcsolatok

SQLServer:Latches-Average Latch Wait Time

SQLServer: Zárolások – Átlagos várakozási idő

SQLServer:Locks-Lock Timeouts/mp

SQLServer: Zárak – Holtpontok száma/mp

SQLServer: Memóriakezelő – Memóriatámogatások függőben

Állítsa be az egyes számlálók értékét az alapértékek és a teszteléssel megjelenített referenciaértékek közé. Például beállíthat egy értesítést, ha a mérő eléri a legmagasabb terhelési érték 75 százalékát, és egy figyelmeztető üzenetet, ha az meghaladja a 90 százalékot.

A riasztások végrehajtásához használhat ingyenes eszközöket, például SQL Server Alerts & Notifications, System Monitor, vagy vásárolhat Microsoft Operations Manager (MOM) vagy más eszközöket. Azt javaslom, hogy legalább a következő helyzetekre állítson be riasztásokat:

• működést érintő hibák, különösen a 19-25 súlyossági pontszámú hibák
• blokkolása
• CPU használat
• lemezhasználat
• szkennelés (SQLServer: Hozzáférési módszerek)

Riasztások küldhetők a rendszergazdák értesítésére e-mailben, személyhívón vagy hálózaton keresztül. Automatikus riasztásokat állíthat be a következő üzenetforrásokhoz:

• SQL Server napló
• SQL Agent napló
• Windows alkalmazásnapló, biztonság és rendszer
• SQL Server feladatvégrehajtási napló

Végül gondoskodnia kell arról, hogy saját alkalmazásai helyesen naplózzák a hibákat, és válaszoljanak a többi fejlesztett alkalmazások hibaüzeneteire is.

Az SQL Server teljesítményének proaktív nyomon követése azt jelenti, hogy mind a kiszolgáló, mind az alkalmazás teljesítményparamétereinek alapértékeit kell meghatározni; referenciaértékek beállítása, amelyek szimulálják a kiszolgáló viselkedését egy előre meghatározott forgatókönyv szerint, és ütemezett megfigyelés, ideális esetben riasztások kiváltása probléma észlelésekor. Függetlenül attól, hogy ingyenes vagy beépített eszközöket használ, vagy harmadik féltől származó megoldásokat választ, az irányítás biztosítja, hogy amikor szüksége van rá, megkapja a szükséges információkat arról, hogyan futnak az alkalmazások az SQL Serveren.

1. táblázat: Rendszerfigyelő objektumok és számlálók az alapvető paraméterek meghatározásához

Tárgy és számláló	Leírás
Memória-oldal/mp	A lemezre olvasott vagy írt oldalak száma másodpercenként. Ez a számláló a rendszerkésések vagy teljesítményproblémák által okozott hibatípusok elsődleges mutatója
Hálózati interfész-Bájtok összesen/sec	A hálózati interfészen másodpercenként áthaladó bájtok száma. Ha ez a számláló ilyen módon csökken vagy trendet mutat, az azt jelzi, hogy hálózati problémák érinthetik az alkalmazást
PhysicalDisk-Disk Transfers/mp	A lemez olvasási/írási műveleteinek becslése. Állítson be számlálót a kiszolgálón lévő minden egyes fizikai lemezhez
Processzor-% Processzoridő	Az idő százalékos aránya, amelyet a processzor egy munkaszál végrehajtásával tölt. Ez a számláló a processzor tevékenységének elsődleges mutatójaként működik. Ha az SQL Serveren futó összes processzor 100%-os kihasználtságot mutat, akkor a végfelhasználói lekérdezéseket valószínűleg figyelmen kívül hagyja.
SQLServer: Hozzáférési módszerek – Teljes vizsgálat/mp	Korlátlan számú táblázat- vagy indexvizsgálat másodpercenként. Ennek a számlálónak a csökkentése jobb, mert a nézetek gyakran erőforrás-kiesést és gyorsítótárazási problémákat okoznak
SQLServer: pufferkezelő-puffer gyorsítótár találati aránya	Azon oldalak százalékos aránya, amelyek nem igényeltek lemezolvasást. Minél nagyobb számuk, annál kevesebb lemez I/O kerül végrehajtásra. Egy jól hangolt rendszeren ennek az értéknek 80-nak vagy magasabbnak kell lennie.
SQLServer:Databases-Log Growths	Mennyit nőtt a tranzakciós fájl egy adott adatbázishoz? Egy jól hangolt rendszeren ennek a számlálónak alacsonynak kell lennie, valószínűleg néhány naponta kevesebb, mint egy
SQLServer:Databases Application Database-Percent Log	A szabad terület százalékos aránya a naplófájlban. Ez a számláló a tervek szerint változik, de nem érheti el a 100-at
SQLServer:Databases Application Database-Transactions/sec	Az adatbázisban visszaigazolt tranzakciók száma. Ez a számláló időnként kimarad a szabványokból. Figyelje meg, mikor kezdődnek a tranzakciók sorba állni, ez azt jelzi, hogy a lemez I/O lassú lehet
SQLServer:Latches-Average Latch Wait Time	A kérés átlagos időtartama, mielőtt kitöltik. Ez a számlálóérték magas lehet, ha a szerver versengésben van az erőforrásokért, különösen a memóriáért vagy az I/O-ért
SQLServer: Zárolások – Átlagos várakozási idő, Zárolási várakozások/mp, Holtpontok száma/s	Az ideiglenes zárak az SQL Server erőforrásait tárolják. Figyelje meg a zárral kapcsolatos számlálók emelkedő tendenciáját, ami egy lehetséges teljesítményproblémát jelez
SQLServer: Általános statisztika-felhasználói kapcsolatok	Az adatbázis-kiszolgálóhoz fűződő felhasználói kapcsolatok száma. Ellenőrizze, hogy nincs-e észrevehető eltolódás a számláló értékében. Jelezhetik a hálózati problémákat, valamint jelezhetik a terhelést és a lassulást
SQLServer: Memóriakezelő – Memóriatámogatások függőben	A memóriaterület lefoglalására váró folyamatok jelenlegi száma. A magas vagy növekvő érték elégtelen memóriakapacitást jelezhet
SQLServer:User Settable-Query (nyomkövető lekérdezés)	Speciális számláló, más néven lekérdezési index. Ez a számláló egy felhasználó által generált lekérdezés, amely jelzi a rendszer általános sebességét vagy hatékonyságát. Az érték beállításához az alkalmazás meghívja az sp_user_counter1 paramétert, és egy numerikus értéket ad vissza.

Valószínűleg minden adatbázis-adminisztrátornak szembesülnie kellett azzal, hogy minden lassan vagy egyáltalán nem működik. Az első dolog, amit meg kell találnia, hogy valójában mi történik jelenleg az SQL Serveren. Úgy tűnik, hogy az adminisztrátornak sok hasznos dolog van a tarsolyában: egy ostoba Activity Monitor, egy csomó Dynamic Management View (dmv), tárolt sp_who és sp_who2 eljárások, amelyeket az SQL Server 7 és az SQL Server 2000 idejéből örököltek.
De találjuk ki...

Monitoring eszközök

Activity Monitor

Remek dolognak tűnik, pontosan azt csinálja, amit kell – figyeli a tevékenységet. Elindítok egy súlyos könyvelési jelentést, és megnézem, mit mutat az Activity Monitor.
A képernyőképeken egy tevékenységfigyelő látható az SQL Server 2005-ből:

és az SQL Server Denali (2012) CTP 3-ból.


Hmmm. Mi van, ha egy tucat ember készít ilyen jelentéseket? És ez nem ritka... Elég kényelmetlen lesz kitalálni, bár persze a fejlődés nyilvánvaló. A Denali Activity Monitor sokkal hasznosabb információkat mutat (például, hogy melyik erőforráson zajlik a várakozás), plusz például közvetlenül a monitorról indíthatunk profilkészítőt a kívánt munkamenethez, és már a profilozóban nyomon követhetjük. , de a fenébe is, ráadásul betölt, és egy már túlterhelt szerver. Ráadásul már a fékekkel is van probléma, és nem fogjuk látni azokat a kéréseket, amelyek végrehajtása a profilozó elindításakor már megkezdődött.
És pontosan ezt szeretném látni – ki mit csinál éppen.

sp_who és sp_who2

A képernyőkép az sp_who (fent) és az sp_who2 (lent) végrehajtásának eredményét mutatja, amelyek ugyanazon rossz sorsú jelentés elkészítése közben futnak:


Igen. Nagyon informatív. Az sp_who-t nézve csak azt látjuk, hogy valami fut. Természetesen végrehajtódik – ezért nézzük, de azt látjuk, hogy valamiféle KIVÁLASZTÁS van végrehajtva. Vagy több SELECT.
Az sp_who2 több információt mutat. Most láthatjuk, hogy mennyi processzoridőt költött a munkamenet (és összeadjuk a teljes időt egy oszlopban, látszólag), az i/o műveletek számát, annak az adatbázisnak a nevét, amelyben mindezt végrehajtják, és kik végzik ezt. munkamenet blokkolva van (ha blokkolva van).
Az Activity Monitor, mint látjuk, több információval szolgál.

DMV

Az SQL Server 2005-től kezdve új lehetőségünk van a kiszolgáló állapotával kapcsolatos információk megszerzésére – a Dynamic Management Views. Az MSDN ezt mondja: "A dinamikus felügyeleti nézetek és függvények a szerver állapotának adatait adják vissza, amelyek felhasználhatók a kiszolgálópéldány állapotának figyelésére, a problémák diagnosztizálására és a teljesítmény hangolására."
Valóban, az SQL Server 2005-ben van egy sor a lekérdezések végrehajtásához kapcsolódó nézetek jelen pillanatban (azonban vannak nézetek az „előzmények” megtekintésére is): itt vannak, és a számuk folyamatosan növekszik verzióról verzióra!
Bizonyára a tapasztalt rendszergazdáknak készen állnak egy csomó szkript, hogy információt szerezzenek a szerver aktuális állapotáról, de mi a teendő, ha még nincs tapasztalata a DMV-vel, de már vannak problémák?

sp_WhoIsActive

Adam Machanic (SQL Server MVP és MCITP) kifejlesztette és folyamatosan fejleszti az sp_WhoIsActive tárolt eljárást, amely ugyanazokra a DMV-kre támaszkodik, és baromi könnyen használható. Letöltheti az sp_WhoIsActive legújabb verzióját. Ádámnak van egy cikksorozata az sp_WhoIsActive-nak szentelve, ami akár 30 (harminc!) darabból áll, elolvashatod, de igyekszem felkelteni az érdeklődésed az anyag elolvasása iránt :).
Tehát feltételezzük, hogy letöltötte és futtatta ezt a szkriptet az egyik tesztkiszolgálón (bármilyen verzión, 2005-től Denaliig). Ádám azt tanácsolja, hogy tárolja a fő rendszer adatbázisában, hogy bármely adatbázisban meghívható legyen, de ez nem szükséges, csak ha egy másik adatbázis kontextusában hívja, akkor a teljes nevet kell írnia - DB .schema.sp_whoIsActive.
Szóval próbáljuk ki. A képernyőkép a végrehajtás eredményét mutatja, miközben ugyanazt a jelentést készíti:

Az exec sp_whoIsActive lekérdezés eredménye sajnos nem fér bele egy képernyőbe, ezért itt van egy paraméterek nélkül meghívott tárolt eljárás kimenetének szöveges leírása.

• - aktív kérés esetén a végrehajtási időt mutatja, „alvó” munkamenet esetén - az „alvó” időt;
• - valójában spid;
• - megjeleníti az éppen végrehajtott kérés szövegét, vagy az utolsó teljesített kérés szövegét, ha a munkamenet alvó állapotban van;
• - Nos, érted;
• - egy nagyon érdekes rovat. A kimenet az (Ax: Bms/Cms/Dms)E formátumban történik. A az E erőforráson várakozó feladatok száma. B/C/D a várakozási idő ezredmásodpercben. Ha csak egy munkamenet vár egy erőforrás felszabadítására (mint a képernyőképen), akkor annak várakozási ideje jelenik meg, ha 2 munkamenet van, azok várakozási ideje B/C formátumban jelenik meg. Ha 3 vagy többen várakoznak, akkor EZEN az erőforráson B/C/D formátumban fogjuk látni a minimális, átlagos és maximális várakozási időt;
• - aktív kérés esetén - a kérés által eltöltött teljes CPU-idő, alvó munkamenet esetén - a teljes CPU-idő a munkamenet „teljes élettartama” alatt;
• - aktív lekérdezés esetén ez az írási műveletek száma a TempDB-ben a lekérdezés végrehajtása során; alvó munkamenet esetén - a TempDB rekordok teljes száma a munkamenet teljes élettartama alatt;
• - aktív kérés esetén - az ehhez a kéréshez hozzárendelt oldalak száma a TempDB-ben; alvó munkamenet esetén - a TempDB-ben a munkamenet teljes élettartama alatt lefoglalt oldalak teljes száma;
• - ha hirtelen letilt minket valaki, akkor a blokkolt személy spidjét (session_id) fogja mutatni;
• - aktív kérés esetén - a kérés végrehajtásakor végrehajtott logikai olvasások száma; alvó munkamenet esetén - a munkamenet teljes élettartama alatt elolvasott oldalak száma;
• - minden ugyanaz, csak a felvételről;
• - aktív kérés esetén - a kérés végrehajtásakor végrehajtott fizikai leolvasások száma; alvó ülésre - hagyományosan a fizikai leolvasások teljes száma az ülés teljes időtartama alatt;
• - aktív kérés esetén - a kérés végrehajtása során felhasznált nyolc kilobájtos oldalak száma; alvó munkamenethez - hány teljes memóriaoldalt foglaltak le a teljes élettartama során;
• - munkamenet állapota - futás, alvás stb.;
• - mutatja az ezzel a munkamenettel megnyitott tranzakciók számát;
• - lehetőség szerint megmutatja a művelet előrehaladását (például MENTÉS, VISSZAÁLLÍTÁS), soha nem mutatja meg, hogy a KIVÁLASZTÁS hány százaléka fejeződött be.

A fennmaradó oszlopok be szabványos kimenet Az sp_WhoIsActive keveset érdekel, és nem írom le őket - a céljuk szerintem mindenki számára világos (host_name, adatbázisnév, programnév, start_time, login_time, request_id, collection_time).

Szóval mi van? Ez minden?

Nem, ez még nem minden. Arról is beszélek, hogy milyen (szempontom szerint a legérdekesebb és leghasznosabb) paraméterekkel hívhatod meg az sp_WhoIsActive-t, és mi sül ki belőle.

• A @help egy borzasztóan hasznos lehetőség. Ha az sp_whoIsActive @help = 1-et hívjuk, akkor az ÖSSZES paraméterről és kimeneti oszlopról információt kapunk a képernyőn. Tehát ha valami nem világos, mindig megtekintheti a „súgót”
• @filter_type és @filter - lehetővé teszi a végrehajtási eredmény szűrését. A @filter_type a "session", "program", "database", "login" és "host" értékeket veheti fel. A @filter paraméterben jelezzük, hogy a kiválasztott típusból melyik objektum érdekel bennünket. Például az összes munkamenetet szeretnénk látni a fő adatbázisban, ehhez hívjuk az exec sp_whoIsActive @filter_type = "adatbázis", @filter = "master" parancsot. A @filter paraméter lehetővé teszi a "%" használatát;
• @not_filter_type és @not_filter – lehetővé teszi számunkra, hogy „fordítva” szűrjünk. Vagyis például mindent látni akarunk, kivéve azokat a munkameneteket, amelyeknél az „adatbázis” mezőben „master” szerepel, ehhez az exec sp_WhoIsActive @not_filter_type = „database”, @not_filter = „master” parancsot hajtjuk végre. Nos, vagy látni akarjuk, mit csinál az összes felhasználó, kivéve a user sa-t... Sok alkalmazás lehet. A @not_filter paraméter lehetővé teszi a "%" használatát;
• @show_system_spids = 1 - információkat jelenít meg a rendszermunkamenetekről;
• @get_full_inner_text = 1 - az sql_text mező nem csak az aktuális kérés (utasítás) szövegét fogja tartalmazni a kötegben (batch), hanem a teljes köteg szövegét;
• @get_plans - a kimenethez hozzáad egy oszlopot a lekérdezés végrehajtási terveivel;
• @get_transaction_info = 1 - hozzáadja a kimenethez a tranzakciós naplók bejegyzéseinek számát és mennyiségét, valamint az utolsó tranzakció kezdő időpontját;
• @get_locks = 1 - hozzáadja a kimeneti információkat a kérés végrehajtása során alkalmazott összes zárolásról;
• @find_block_leaders = 1 - nyomon követi a blokkolási láncot, és megmutatja a blokk eltávolítására váró munkamenetek teljes számát;
• @output_column_list = "[%]" - mi a teendő, ha nem akarod látni a tempDB információkat az sp_whoIsActive kimenetben? Ezzel az opcióval szabályozhatja, hogy mit adjon ki;
• @destination_table = "tábla_neve" - ​​megpróbálja beszúrni a végrehajtás eredményét egy táblába, de nem ellenőrzi, hogy ez a tábla létezik-e, és hogy van-e elegendő jogosultság a beillesztéshez.

Most ennyi

Ennek eredményeként van egy másik rendkívül kényelmes és rugalmas eszközünk az SQL Server aktuális tevékenységeinek nyomon követésére. Normál működéséhez elegendő a VIEW SERVER STATE engedély és a dmv hozzáférési jogosultsága.
Akkor is érdemes hozzátenni, ha a szerverhez csak keresztül lehet csatlakozni

Teljesítmény-ellenőrzési ellenőrzőlista

Írja be az eredményeket a fenti táblázatba.

A Performance Monitor használata az SQL Server hardveres szűk keresztmetszetek azonosítására

A legjobb hely az SQL Server teljesítményének ellenőrzéséhez a Performance Monitor (Rendszerfigyelő) segítségével. Néhány kulcsszámláló figyelése egy 24 órás időszak alatt meglehetősen jó képet ad az SQL Server teljesítményét befolyásoló komoly hardverproblémákról.

Ideális esetben a teljesítményfigyelő segítségével 24 órás naplót készíthet a legfontosabb mérőállásokról. A naplófájl létrehozásához egy "tipikus" 24 órás időszakot kell kiválasztania.

Például válasszon egy tipikus hétköznapot, ne a hét végét vagy ünnepnapot.

Miután rögzítette a 24 órás Performance Monitor adatokat egy naplófájlban, jelenítse meg az ajánlott számlálókat a Teljesítményfigyelő diagram módban, majd rögzítse az átlagos, minimális és maximális értékeket a fenti táblázatban. Ha ezt megtette, hasonlítsa össze eredményeit az alábbi elemzés eredményeivel. Ez az összehasonlítás lehetőséget ad az SQL Servert érintő esetleges hardveres szűk keresztmetszetek azonosítására.

A kulcsteljesítmény-figyelő számlálók értelmezése

Az alábbiakban bemutatunk néhány alapvető teljesítményfigyelő számlálót, azok javasolt értékeit, valamint néhány olyan opciót, amelyek segíthetnek azonosítani és megoldani a hardverproblémákat. Megjegyzendő, hogy korlátoztam a figyelembe vett teljesítményfigyelő számlálók számát. Ez azért van így, mert ennek a cikknek az a célja, hogy feltárja a termelékenység csökkenésével kapcsolatos egyszerű és nyilvánvaló problémákat. Számos más teljesítményfigyelő számlálóról olvashat a webhely más helyén.

Memória: oldal/másodperc

Feltételezve, hogy az SQL Server az egyetlen fő alkalmazás, amely a kiszolgálón fut, ennek a számnak ideális esetben nulla és 20 között kell lennie. Nagyon valószínű, hogy jóval 20 feletti kiugró értékeket fog látni, ami teljesen normális. Itt az a kulcs, hogy az átlagos oldalárfolyam 20 alatt maradjon.

Ha a szervere átlagosan több mint 20 oldalt nyomtat másodpercenként, ennek egyik legvalószínűbb oka a szükséges RAM hiánya. Általánosságban elmondható, hogy minél több RAM áll rendelkezésre, annál kevesebb oldalcserét kell végrehajtani.

A legtöbb esetben egy megfelelő RAM-mal rendelkező SQL Serverhez dedikált fizikai szerveren az átlagos oldalcsere kevesebb, mint 20. Az SQL Server megfelelő RAM-ja a következő kritérium alapján határozható meg: a kiszolgálónak rendelkeznie kell puffer-gyorsítótár találati aránnyal (Buffer Hit Cache Ratio) 99% vagy magasabb. Ezt a számlálót a cikk későbbi részében ismertetjük. Ha olyan SQL Serverrel rendelkezik, amelynél ez az arány 99% vagy magasabb egy 24 órás időszak alatt, de az átlagos oldalváltási árfolyam 20 felett van ugyanebben az időszakban, ez azt jelezheti, hogy más alkalmazásokat is futtat az SQL Servertől eltérő fizikai szerver. Ha ez a helyzet, akkor ideális esetben el kell távolítania ezeket az alkalmazásokat, lehetővé téve, hogy az SQL Server legyen az egyetlen fő alkalmazás a fizikai kiszolgálón.

Ha az SQL Server nem futtat más alkalmazást, és az oldalcsere 24 órán belül átlagosan meghaladja a 20-at, ez azt jelentheti, hogy módosította az SQL Server memóriabeállításait. Az SQL Servert úgy kell konfigurálni, hogy az "SQL Server memória dinamikus konfigurálása" opció legyen beállítva, a "Maximális memória" beállítás pedig a legmagasabb értékre legyen állítva. Az optimális működés érdekében meg kell engedni, hogy az SQL Server annyi RAM-ot vegyen fel, amennyire szüksége van, anélkül, hogy versenyeznie kellene a RAMért más alkalmazásokkal.

Memória: Szabad hely

Egy másik módja annak, hogy megtudja, hogy az SQL Server rendelkezik-e elegendő fizikai RAM-mal, ha ellenőrzi a Memory Object: Available Bytes számlálót. Az értékének 5 MB-nál nagyobbnak kell lennie. Ellenkező esetben az SQL Servernek több fizikai RAM-ra van szüksége. Az SQL Serverre specializálódott szerveren az utóbbi 4-10 MB szabad fizikai memóriát próbál megtartani. A fennmaradó fizikai RAM-ot az operációs rendszer és az SQL Server használja. Ha a rendelkezésre álló memória megközelíti az 5 MB-ot vagy az alatti, akkor a legvalószínűbb, hogy az SQL Server túlterhelést tapasztal a kevés memória miatt. Ebben az esetben növelnie kell a kiszolgáló fizikai RAM mennyiségét, csökkentenie kell a szerver terhelését, vagy ennek megfelelően módosítania kell az SQL Server memória konfigurációs beállításait.

Fizikai lemez: Lemez üzemidő %

Ez a számláló azt mutatja, hogy a fizikai lemeztömb mennyire foglalt (nem logikai partíció vagy a tömbben lévő egyedi lemez). Jó relatív mérést ad a lemeztömbök elfoglaltságáról.

Ökölszabályként a lemezidő-számlálónak 55%-nál kevesebbet kell mutatnia.

Ha a számláló értékek meghaladják az 55%-ot folyamatos időszakokra (több mint 10 percre a 24 órás megfigyelés során), akkor előfordulhat, hogy az SQL Server I/O problémákat tapasztal. Ha a 24 órás megfigyelés alatt csak alkalmanként látja ezt a viselkedést, nem aggódnék túlzottan, de ha gyakran előfordulna (mondjuk óránként többször), akkor elkezdenék keresni az I/O teljesítmény növelésének módjait. a szerveren, vagy csökkentse a szerver terhelését. A lemez I/O növelésének néhány módja: új lemezek hozzáadása a tömbhöz (ha lehetséges), a lemezek cseréje gyorsabbakra, gyorsítótár hozzáadása a vezérlőkártyához (ha lehetséges), a RAID különböző verzióinak használata, vagy gyorsabb vezérlő telepítése. .

Mielőtt ezt a számlálót NT 4.0 alatt használná, manuálisan kell engedélyeznie, ehhez írja be a következőt a parancssorba: "diskperf-y". Ezt követően újra kell indítania a szervert. Ezért azonnal engedélyeznie kell a lemezszámlálókat a Windows NT 4.0 alatt. Ha Windows 2000 rendszert futtat, ez a számláló alapértelmezés szerint engedélyezve van.

A "Physical Disk: Disk Uptime" számláló értékének figyelése mellett az átlagos lemezsorhossz-számláló értékét is célszerű figyelni (Avg. Disk Queue Length). Ha ez az érték meghaladja a 2-t folyamatos időszakokban (több mint 10 perc a 24 órás megfigyelési periódus alatt) a tömb minden egyes meghajtójára vonatkozóan, akkor a tömb a rendszer teljesítményét szűk keresztmetszetet jelenthet. A lemezidőzítőhöz hasonlóan, ha ez a 24 órás megfigyelési periódusban időnként megtörténik, nem aggódnék túl sokat, de ha gyakran előfordul, akkor elkezdenék keresni a lehetőségeket a szerver I/O teljesítményének növelésére a leírtak szerint. felett.

Ezt a számot ki kell számítania, mert a Performance Monitor nem tudja, hogy hány fizikai lemez van a tömbben. Például, ha van egy 6 fizikai lemezből álló tömbje, és az átlagos várólista hossza 10 ehhez a tömbhöz, akkor a tényleges átlagos lemezsor lemezenként 1,66 (10/6=1,66), ami jócskán az ajánlott 2-es tartományon belül van. by-1 fizikai lemez.

Mielőtt ezt a számlálót NT 4.0 alatt használná, manuálisan engedélyezze a „diskperf-y” beírásával az NT parancssorba, majd indítsa újra a szervert. Ezért a Windows NT 4.0 telepítése után azonnal engedélyezni kell a lemezszámlálókat. Ha Windows 2000 rendszert használ, ez a számláló alapértelmezés szerint engedélyezve lesz.

Használja mindkét fent leírt számlálót, hogy pontosan megtudja, hogy a szerverén vannak-e I/O problémák. Ha például sok olyan időszakot lát, amikor a lemez üzemideje meghaladja az 55%-ot, és amikor az átlagos lemezsor hossza meghaladja a 2-t fizikai lemezenként, akkor biztos lehet benne, hogy a kiszolgálónak I/O problémája van.

Processzor: CPU idő %

A Processor Object: % Processor Time számláló minden CPU-hoz elérhető, és megbecsüli az egyes CPU-k használatát. Hasonló számláló is elérhető a központi processzorok teljes készletéhez (teljes szám). Ez egy kulcsszámláló a CPU-használat figyeléséhez. Ha ennek a számlálónak a teljes processzorbetöltési ideje meghaladja a 80%-ot folyamatos időszakokban (24 órás megfigyelési periódusban több mint 10 perc), akkor a CPU-t tekintheti a rendszer szűk keresztmetszetének. Ha ezek a nagy terheléses időszakok időnként előfordulnak, és úgy gondolod, hogy együtt tudsz élni vele, akkor minden rendben van. Ha azonban gyakran előfordulnak, érdemes megfontolni a szerverterhelés csökkentésének lehetőségeit, például gyorsabb CPU-k vásárlását, több CPU telepítését vagy nagyobb beépített L2-gyorsítótárral rendelkező CPU-k vásárlását.

Rendszer: CPU sor hossza

A CPU-időszámláló mellett figyelnie kell a Processor Queue Length számlálót is. Ha ez a sebesség meghaladja a 2-t CPU-nként folyamatos időszakokban (több mint 10 perc a 24 órás megfigyelési periódus alatt), akkor ez valószínűleg a rendszer szűk keresztmetszete. Például, ha a szervere 4 CPU-val rendelkezik, a CPU-sor hossza összesen nem haladhatja meg a 8-at.

Ha a CPU-sor hossza rendszeresen meghaladja az ajánlott maximumot, de a CPU kihasználtsága nem olyan magas (ami a tipikus eset), akkor fontolja meg az SQL Server "max worker threads" konfigurációs paraméterének csökkentését.

A CPU hosszú várakozási sorának lehetséges oka az, hogy túl sok dolgozó szál várja a sorát. Számuk csökkentése, amit ezzel a paraméterrel tesz, arra kényszeríti a szál pooling használatát (ha ez még nem így van), vagy növeli a szerepét.

SQL Server puffer: puffer gyorsítótár találati aránya

Ez a számláló (SQL Server Buffer: Buffer Cache Hit Ratio) azt mutatja, hogy az SQL Server milyen gyakran fér hozzá a pufferhez, nem pedig a merevlemezhez az adatok lekéréséhez. OLTP-alkalmazásokban ennek az aránynak meg kell haladnia a 90%-ot, és ideális esetben nagyobbnak kell lennie 99%-nál. Ha a puffer gyorsítótár találati aránya 90% alatt van, érdemes még ma vásárolnia több RAM-ot. Ha ez az arány 90% és 99% között van, akkor komolyan meg kell fontolnia több RAM vásárlását, mivel minél közelebb kerül a 99%-hoz, annál gyorsabban fog futni az SQL Server. Egyes esetekben, ha az adatbázis nagyon nagy, akkor sem tudja megközelíteni a 99%-ot, ha a maximális mennyiségű RAM-ot helyezi a szerverére. Ezután csak annyit tehet, hogy a lehető legtöbb memóriát hozzáadja, és elfogadja a status quót.

Az OLAP-alkalmazásokban az arány az OLAP-alkalmazás jellegéből adódóan jóval alacsonyabb is lehet. Akárhogy is, a RAM növelése felgyorsítja az SQL Servert.

SQL Server: Felhasználói kapcsolatok

Mivel az SQL Server felhasználóinak száma befolyásolja a teljesítményét, ajánlott figyelni a felhasználói kapcsolatok számlálóját (SQL Server Általános statisztikai objektum: Felhasználói kapcsolatok számlálója). A felhasználói kapcsolatok számát mutatja, nem pedig az SQL Serverhez egy adott időpontban csatlakozott felhasználók számát.

Ha ez a számláló nagyobb, mint 255, növelje meg a "Maximális dolgozói szálak" konfigurációs paramétert, amely alapértelmezés szerint 255. Ha a kapcsolatok száma meghaladja a rendelkezésre álló munkaszálak számát, az SQL Server megkezdi a munkaszálak megosztását, ami negatívan hathat. hatásteljesítmény. Ennek a paraméternek a beállításának magasabbnak kell lennie, mint a kiszolgálón elérhető kapcsolatok maximális száma.

Mi lesz ezután

Bár sokkal több számláló létezik, mint az általunk tárgyalt, ez utóbbiak kulcsfontosságúak a teljesítmény-ellenőrzési folyamat során előforduló nyomon követésben. Miután befejezte a Performance Monitor elemzését, használja a cikksorozatban található ajánlásokat a szükséges változtatások végrehajtásához, amelyek az SQL Server megfelelő teljesítményét biztosítják.

Valószínűleg minden adatbázis-adminisztrátornak szembesülnie kellett azzal, hogy minden lassan vagy egyáltalán nem működik. Az első dolog, amit meg kell találnia, hogy valójában mi történik jelenleg az SQL Serveren. Úgy tűnik, hogy az adminisztrátornak sok hasznos dolog van a tarsolyában: egy ostoba Activity Monitor, egy csomó Dynamic Management View (dmv), tárolt sp_who és sp_who2 eljárások, amelyeket az SQL Server 7 és az SQL Server 2000 idejéből örököltek.
De találjuk ki...

Monitoring eszközök

Activity Monitor

Remek dolognak tűnik, pontosan azt csinálja, amit kell – figyeli a tevékenységet. Elindítok egy súlyos könyvelési jelentést, és megnézem, mit mutat az Activity Monitor.
A képernyőképeken egy tevékenységfigyelő látható az SQL Server 2005-ből:

És az SQL Server Denali (2012) CTP 3-ból.


Hmmm. Mi van, ha egy tucat ember készít ilyen jelentéseket? És ez nem ritka... Elég kényelmetlen lesz kitalálni, bár persze a fejlődés nyilvánvaló. A Denali Activity Monitor sokkal hasznosabb információkat mutat (például, hogy melyik erőforráson zajlik a várakozás), plusz például közvetlenül a monitorról indíthatunk profilkészítőt a kívánt munkamenethez, és már a profilozóban nyomon követhetjük. , de a fenébe is, ráadásul betölt, és egy már túlterhelt szerver. Ráadásul már a fékekkel is van probléma, és nem fogjuk látni azokat a kéréseket, amelyek végrehajtása a profilozó elindításakor már megkezdődött.
És pontosan ezt szeretném látni – ki mit csinál éppen.

sp_who és sp_who2

A képernyőkép az sp_who (fent) és az sp_who2 (lent) végrehajtásának eredményét mutatja, amelyek ugyanazon rossz sorsú jelentés elkészítése közben futnak:


Igen. Nagyon informatív. Az sp_who-t nézve csak azt látjuk, hogy valami fut. Természetesen végrehajtódik – ezért nézzük, de azt látjuk, hogy valamiféle KIVÁLASZTÁS van végrehajtva. Vagy több SELECT.
Az sp_who2 több információt mutat. Most láthatjuk, hogy mennyi processzoridőt költött a munkamenet (és összeadjuk a teljes időt egy oszlopban, látszólag), az i/o műveletek számát, annak az adatbázisnak a nevét, amelyben mindezt végrehajtják, és kik végzik ezt. munkamenet blokkolva van (ha blokkolva van).
Az Activity Monitor, mint látjuk, több információval szolgál.

DMV

Az SQL Server 2005-től kezdve új lehetőségünk van a kiszolgáló állapotával kapcsolatos információk megszerzésére – a Dynamic Management Views. Az MSDN ezt mondja: "A dinamikus felügyeleti nézetek és függvények a szerver állapotának adatait adják vissza, amelyek felhasználhatók a kiszolgálópéldány állapotának figyelésére, a problémák diagnosztizálására és a teljesítmény hangolására."
Valóban, az SQL Server 2005-ben van egy sor a lekérdezések végrehajtásához kapcsolódó nézetek jelen pillanatban (azonban vannak nézetek az „előzmények” megtekintésére is): itt vannak, és a számuk folyamatosan növekszik verzióról verzióra!
Bizonyára a tapasztalt rendszergazdáknak készen állnak egy csomó szkript, hogy információt szerezzenek a szerver aktuális állapotáról, de mi a teendő, ha még nincs tapasztalata a DMV-vel, de már vannak problémák?

sp_WhoIsActive

Adam Machanic (SQL Server MVP és MCITP) kifejlesztette és folyamatosan fejleszti az sp_WhoIsActive tárolt eljárást, amely ugyanazokra a DMV-kre támaszkodik, és baromi könnyen használható. Letöltheti az sp_WhoIsActive legújabb verzióját. Ádámnak van egy cikksorozata az sp_WhoIsActive-nak szentelve, ami akár 30 (harminc!) darabból áll, elolvashatod, de igyekszem felkelteni az érdeklődésed az anyag elolvasása iránt :).
Tehát feltételezzük, hogy letöltötte és futtatta ezt a szkriptet az egyik tesztkiszolgálón (bármilyen verzión, 2005-től Denaliig). Ádám azt tanácsolja, hogy tárolja a fő rendszer adatbázisában, hogy bármely adatbázisban meghívható legyen, de ez nem szükséges, csak ha egy másik adatbázis kontextusában hívja, akkor a teljes nevet kell írnia - DB .schema.sp_whoIsActive.
Szóval próbáljuk ki. A képernyőkép a végrehajtás eredményét mutatja, miközben ugyanazt a jelentést készíti:

Az exec sp_whoIsActive lekérdezés eredménye sajnos nem fér bele egy képernyőbe, ezért itt van egy paraméterek nélkül meghívott tárolt eljárás kimenetének szöveges leírása.

• - aktív kérés esetén a végrehajtási időt mutatja, „alvó” munkamenet esetén - az „alvó” időt;
• - valójában spid;
• - megjeleníti az éppen végrehajtott kérés szövegét, vagy az utolsó teljesített kérés szövegét, ha a munkamenet alvó állapotban van;
• - Nos, érted;
• - egy nagyon érdekes rovat. A kimenet az (Ax: Bms/Cms/Dms)E formátumban történik. A az E erőforráson várakozó feladatok száma. B/C/D a várakozási idő ezredmásodpercben. Ha csak egy munkamenet vár egy erőforrás felszabadítására (mint a képernyőképen), akkor annak várakozási ideje jelenik meg, ha 2 munkamenet van, azok várakozási ideje B/C formátumban jelenik meg. Ha 3 vagy többen várakoznak, akkor EZEN az erőforráson B/C/D formátumban fogjuk látni a minimális, átlagos és maximális várakozási időt;
• - aktív kérés esetén - a kérés által eltöltött teljes CPU-idő, alvó munkamenet esetén - a teljes CPU-idő a munkamenet „teljes élettartama” alatt;
• - aktív lekérdezés esetén ez az írási műveletek száma a TempDB-ben a lekérdezés végrehajtása során; alvó munkamenet esetén - a TempDB rekordok teljes száma a munkamenet teljes élettartama alatt;
• - aktív kérés esetén - az ehhez a kéréshez hozzárendelt oldalak száma a TempDB-ben; alvó munkamenet esetén - a TempDB-ben a munkamenet teljes élettartama alatt lefoglalt oldalak teljes száma;
• - ha hirtelen letilt minket valaki, akkor a blokkolt személy spidjét (session_id) fogja mutatni;
• - aktív kérés esetén - a kérés végrehajtásakor végrehajtott logikai olvasások száma; alvó munkamenet esetén - a munkamenet teljes élettartama alatt elolvasott oldalak száma;
• - minden ugyanaz, csak a felvételről;
• - aktív kérés esetén - a kérés végrehajtásakor végrehajtott fizikai leolvasások száma; alvó ülésre - hagyományosan a fizikai leolvasások teljes száma az ülés teljes időtartama alatt;
• - aktív kérés esetén - a kérés végrehajtása során felhasznált nyolc kilobájtos oldalak száma; alvó munkamenethez - hány teljes memóriaoldalt foglaltak le a teljes élettartama során;
• - munkamenet állapota - futás, alvás stb.;
• - mutatja az ezzel a munkamenettel megnyitott tranzakciók számát;
• - lehetőség szerint megmutatja a művelet előrehaladását (például MENTÉS, VISSZAÁLLÍTÁS), soha nem mutatja meg, hogy a KIVÁLASZTÁS hány százaléka fejeződött be.

A fennmaradó oszlopok be szabványos kimenet Az sp_WhoIsActive keveset érdekel, és nem írom le őket - a céljuk szerintem mindenki számára világos (host_name, adatbázisnév, programnév, start_time, login_time, request_id, collection_time).

Szóval mi van? Ez minden?

Nem, ez még nem minden. Arról is beszélek, hogy milyen (szempontom szerint a legérdekesebb és leghasznosabb) paraméterekkel hívhatod meg az sp_WhoIsActive-t, és mi sül ki belőle.

• A @help egy borzasztóan hasznos lehetőség. Ha az sp_whoIsActive @help = 1-et hívjuk, akkor az ÖSSZES paraméterről és kimeneti oszlopról információt kapunk a képernyőn. Tehát ha valami nem világos, mindig megtekintheti a „súgót”
• @filter_type és @filter - lehetővé teszi a végrehajtási eredmény szűrését. A @filter_type a "session", "program", "database", "login" és "host" értékeket veheti fel. A paraméterben jelezzük, hogy a kiválasztott típusból melyik objektum érdekel bennünket. Például látni szeretnénk az összes munkamenetet a fő adatbázisban, ehhez hívjuk az exec sp_whoIsActive @filter_type = "adatbázis", = "master" parancsot. A paraméterben használhatja a "%" értéket;
• @not_filter_type és @not_filter – lehetővé teszi a „fordított” szűrést. Vagyis például mindent látni akarunk, kivéve azokat a munkameneteket, amelyeknél az „adatbázis” mezőben „master” szerepel, ehhez az exec sp_WhoIsActive @not_filter_type = „database”, @not_filter = „master” parancsot hajtjuk végre. Nos, vagy látni akarjuk, mit csinál az összes felhasználó, kivéve a user sa-t... Sok alkalmazás lehet. A @not_filter paraméter lehetővé teszi a "%" használatát;
• @show_system_spids = 1 - információkat jelenít meg a rendszermunkamenetekről;
• @get_full_inner_text = 1 - az sql_text mező nem csak az aktuális kérés (utasítás) szövegét fogja tartalmazni a kötegben (batch), hanem a teljes köteg szövegét;
• @get_plans - a kimenethez hozzáad egy oszlopot a lekérdezés végrehajtási terveivel;
• @get_transaction_info = 1 - hozzáadja a kimenethez a tranzakciós naplók bejegyzéseinek számát és mennyiségét, valamint az utolsó tranzakció kezdő időpontját;
• @get_locks = 1 - hozzáadja a kimeneti információkat a kérés végrehajtása során alkalmazott összes zárolásról;
• @find_block_leaders = 1 - nyomon követi a blokkolási láncot, és megmutatja a blokk eltávolítására váró munkamenetek teljes számát;
• @output_column_list = "[%]" - mi a teendő, ha nem akarod látni a tempDB információkat az sp_whoIsActive kimenetben? Ezzel az opcióval szabályozhatja, hogy mit adjon ki;
• @destination_table = "tábla_neve" - ​​megpróbálja beszúrni a végrehajtás eredményét egy táblába, de nem ellenőrzi, hogy ez a tábla létezik-e, és hogy van-e elegendő jogosultság a beillesztéshez.

Most ennyi

Ennek eredményeként van egy másik rendkívül kényelmes és rugalmas eszközünk az SQL Server aktuális tevékenységeinek nyomon követésére. Normál működéséhez elegendő a VIEW SERVER STATE engedély és a dmv hozzáférési jogosultsága.
Akkor is érdemes hozzátenni, ha a szerverhez csak keresztül lehet csatlakozni