Az SQL Server Activity Monitor használata. A teljesítmény monitor, hogy meghatározzák a szűk a hardver, amelyen az SQL Server fut a legjobb eszközök ellenőrzésére MS SQL Server

Bármely adatbázis adminisztrátor, gondoskodnia kellett azzal, hogy minden lassan működik, vagy egyáltalán nem működik. Az első dolog, amit meg kell találnod, az, hogy jelenleg az SQL Serveren jelenleg történik. Úgy tűnik, hogy az adminisztrátor arzenálja az összes hasznos darabot: egy BUVA tevékenységfigyelő, egy csomó dinamikus menedzsment nézet (DMV), SP_WHO és SP_WHO2 tárolt eljárások, amelyek az SQL Server 7 és az SQL Server 2000 óta örököltek.
De lássuk ...

Monitoring eszközök

Tevékenységi monitor

Úgy tűnik, nagyszerű dolog, hogy részt vesz azzal, hogy szükséges - a tevékenységet figyelemmel kísérik. Nehéz számviteli jelentést indítok, és megnézem, hogy melyik tevékenységfigyelő mutasson meg nekem.
A SCREENSHOTS TEVÉKLET MONITOR Az SQL SERVER 2005-től:

És az SQL Server Denali (2012) CTP 3.


M-igen. És ha egy tucat ember elindítja az ilyen jelentéseket? És ez nem ritka ... meglehetősen kényelmetlen lesz, bár természetesen az arcra halad. A Denali aktivitási monitoron sokkal hasznosabb információt mutat (például az erőforrás-elvárás során), plusz, például a kívánt munkamenethez, futtathatunk egy profileret közvetlenül a monitorból, és nyomon követhetjük már a Profiler, de károsítja, továbbá betölti és betölti a betöltött kiszolgálót. Ezenkívül már van probléma a fékekkel, és azok a kérések, hogy a profilok elindításakor már elkezdték végrehajtani, nem fogjuk látni.
És ezt szeretném látni - ki és mit csinál most.

sP_WHO és SP_WHO2.

A képernyőképen az SP_WHO (felülről) és a SP_WHO2 (alsó) végrehajtásának eredménye a teljes rosszindulatú jelentés építése során:


Igen. Nagyon informatív. A SP_WHO-ra nézve csak azt láthatjuk, hogy mi működik. Természetesen azt hajtják végre - mi vagyunk, és látjuk, és látjuk, hogy bizonyos választás történik. Vagy néhány közül választhat "ov. Nagyszerű.
SP_WHO2 További információkat jelenít meg. Most láthatjuk, hogy mennyi processzor időt töltött az ülésen (és az oszlop teljes időtartamát, látszólag), az I / O műveletek számát, az adatbázis nevét, amelyben mindezt végrehajtják, és akiket ez a munkamenet blokkolja ( Ha blokkolva van).
Tevékenységi monitor, amint azt látjuk, több információt ad.

Dmv

Az SQL Server 2005-el kezdődően új lehetőséget kaptunk a szerver állapotáról - dinamikus menedzsment nézetekről. Az MSDN azt mondja: "Dinamikus közigazgatási nézetek és funkciók visszaadják az adatállapotadatokat, amelyek a kiszolgáló példányának ellenőrzésére használhatók, a probléma diagnosztika és a teljesítménybeállítások."
És valójában a 2005-ös SQL Server "E Van egy nézet, amely a jelenlegi pillanatban bekövetkezett kérések végrehajtásával kapcsolatos nézetek (azonban vannak előadások a" történelem "): Itt vannak. És a számuk, a A verzió verziója továbbra is növekszik!
Bizonyára a Mastic adminisztrátorok sok szkriptel rendelkeznek, így információt kaphat a szerver aktuális állapotáról, de mit kell tennie, ha a DMV-vel való munkavégzés tapasztalata még nem, de már vannak problémák?

sp_whoisaktív

Adam Machanic (SQL Server MVP és MCITP) kifejlesztette és folyamatosan szerényíti a SP_WHOOISACTION tárolt eljárást, amely csak ezeken a legtöbb DMV és a rohadt könnyen használható. Töltse le a SP_WHOISACTION legújabb verzióját. Ádámban van egy sor cikk, amelynek sp_whoisaktív, 30 (harminc!) Darabból áll, olvashatod, és megpróbálom érdeklődni az anyag olvasásában :).
Tehát feltételezzük, hogy letöltötte és elindította ezt a szkriptet az egyik tesztszerveren (2005-től kezdve bármely verzión, és Denalivel végződik). Ádám azt tanácsolja, hogy tárolja a Master System adatbázisban, hogy bármely adatbázis kontextusában lehessen hívni, de nem szükséges, ha egy másik adatbázis összefüggésében hívja fel, akkor a nevet teljesen meg kell írnia a nevet - BD. sham.sp_whoisactive.
Tehát próbáld meg. A képernyőképen, annak végrehajtásának eredménye az egész azonos jelentés építése során:

A EXEC SP_WHOISAKECTIVE, az ALAS, nem létezik egy képernyőn, így a paraméterek nélküli tárolt eljárás kimenetének szöveges leírása.

• - Egy aktív vizsgálat esetén a végrehajtási idő mutatja az "alvó" munkamenetet - az "alvás" időt;
• - valójában, Spid;
• - Megmutatja a jelenleg végrehajtott szöveget, vagy az utolsó végrehajtott lekérdezés szövegét, ha a munkamenet alszik;
• - Nos, megértetted;
• - Nagyon érdekes oszlop. Megjelenik a formátumban (AX: BMS / CMS / DMS) E. A az E. b / c / d erőforrás várakozási feladatainak száma - ez várakozási idő milliszekundumban. Ha az erőforrás csak egy munkamenetet vár (mint a screenshot), várakozási ideje megjelenik, ha 2 munkamenet a várakozási időtartama B / C formátumban. Ha 3 vagy annál többet vársz - a B / C / D formátumban a minimális, átlagos és maximális várakozási időt fogjuk látni;
• - Az aktív vizsgálathoz - a CPU teljes időpontja, amelyet ebben a kérésen keresztül töltöttek, az alvási munkamenethez - a CPU teljes időpontja az ülés minden életében;
• - Aktív lekérdezés esetén ez a lekérdezés végrehajtása során a TEMPDB rögzítési műveleteinek száma; Alvási munkamenethez - a TEMPDB-ben lévő bejegyzések száma az ülés minden életében;
• - aktív lekérdezéshez - a kéréshez rendelt TempdB oldalak száma; Az alvási munkamenethez - az ülés teljes élettartamához rendelt TempdB oldalak száma;
• - Ha hirtelen blokkolja valakit, Spid (Session_ID) megmutatja, hogy ki blokkoltunk;
• - aktív lekérdezéshez - a kérés végrehajtásakor végrehajtott logikai leolvasások száma; Az alvási munkamenethez - az olvasási oldalak száma az ülés minden élettartamához;
• - ugyanaz, de a rekordról;
• - aktív lekérdezés esetén - a kérés végrehajtása során végrehajtott fizikai leolvasások száma; Az alvási munkamenethez - hagyományosan az ülés teljes élettartamának fizikai méréseinek teljes száma;
• - egy aktív lekérdezéshez - a kérés végrehajtásában használt nyolc kilobyt oldalak száma; Az alvási munkamenethez - hány perc memóriaoldalt emeltek ki minden életében;
• - a munkamenet állapota végrehajtásra kerül, alszik stb.;
• - megmutatja a nyitott munkamenet tranzakcióinak számát;
• - Megmutatja, hogy van-e ilyen lehetőség, az üzemeltetési folyamat (például biztonsági mentés, visszaállítás), soha ne mutassa meg, hogy a kiválasztás mennyi százaléka van végrehajtva.

A fennmaradó oszlopok B. szabvány kimenet SP_WHOISACTICE érdekesnek tűnik, és nem fogom leírni őket - a céljukat, azt hiszem, mindenki számára érthető (Host_Name, Database_Name, Program_Name, Start_Time, Login_Time, Request_ID, Collection_Time).

És akkor? Ez minden?

Nem, ez nem minden. Azt is elmondom, hogy mit (a legérdekesebb és hasznos, az én szempontból) paraméterek lehetnek SP_WHOISACTIKA, és mi fog működni.

• @help szörnyű hasznos paraméter. A SP_WHOISACTIONE @HELP \u003d 1 hívásakor információkat kapunk a képernyő összes paraméteréről és kimeneti oszlopáról. Tehát, ha valami nem érhető el, akkor mindig is megtekintheti a "súgót"
• @Filter_type és @Filter - Engedje meg, hogy szűrje a végrehajtás eredményét. @Filter_type elfogadhatja a "Session", "Program", "Adatbázis", "Bejelentkezés" és "Host" elfogadását. A paraméterben megadjuk a kiválasztott típus melyik objektumát érdekelt számunkra. Például szeretnénk látni a mester adatbázisban futó összes ülést, ezért hívjuk a SP_WHOISACTION @FILTER_TYPE \u003d "DATABASE", \u003d "MASTER" címet. A paraméter megengedett a "%" használatára;
• @not_filter_type és @not_filter - Engedélyezzünk, hogy "ellenkezőleg" legyen ". Azok, például azt szeretnénk látni mindent, kivéve azokat a munkameneteket, amelyek az adatbázis mezőben "Master" állnak, ezért végrehajtjuk a SP_WHOISACTION @NOT_FILTER_TYPE \u003d "DATABASE", @NOT_FILTER \u003d "MASTER" gombot. Nos, vagy szeretnénk látni, hogy az összes felhasználó, kivéve a user sa ... alkalmazások beállíthatók. A @not_filter paraméter megengedett a "%" használatára;
• @show_system_spids \u003d 1 - megmutatja a rendszer ülésszakáról szóló információkat;
• @Get_full_inner_text \u003d 1 - Az SQL_Text mezőben nem csak az aktuális kérés szövege (stetiment) a csomagban (batche), és a teljes adagoló szövege teljes egészében;
• @Get_plans - Add hozzá a kimeneti oszlophoz lekérdezési végrehajtási tervekkel;
• @Get_transaction_info \u003d 1 - Hozzáadja a nyilvántartások kimenetét és mennyiségét a tranzakciós naplókhoz, valamint az utolsó tranzakció megkezdéséhez;
• @Get_locks \u003d 1 - hozzáteszi a kimeneti információkat a lekérdezés végrehajtása során kivetett zárakról;
• @find_block_leaders \u003d 1 - követi a zárláncot, és megmutatja az aktuális munkamenet felszabadítására váró munkamenetek teljes számát;
• @Output_column_list \u003d "[%]" - Mi van, ha nem szeretné látni a tempdb információit a SP_WHOISACTICE kimenetében? Ezzel a paraméterrel ellenőrizheti azt a tényt, hogy megjeleníti;
• @Destination_table \u003d "table_name" - megpróbálja beilleszteni a végrehajtás eredményét, hogy írjon az asztalra, de ez a táblázat nem ellenőrzi, hogy elegendő-e behelyezni.

Most mindenki

Ennek eredményeképpen van egy másik rendkívül kényelmes és rugalmas eszközünk az aktuális aktivitás nyomon követésére az SQL Serveren. Normál működéséhez elegendő a View Server állam megoldása és a DMV felkérésének jogai.
Azt is érdemes hozzáadni, abban az esetben, ha csak a szerverhez csatlakoztatható

A teljesítmény ellenőrzési problémáinak listája

Adja meg eredményeit a fenti táblázatban.

A Performance Monitor (teljesítmény monitor) használata a keskeny SQL Server hardveres járművek azonosításához

A legjobb az SQL Server teljesítményének ellenőrzése a Teljesítményfigyelő (Rendszerfigyelő) teljesítményéről. A 24 órás főmérők megfigyelése lehetővé teszi, hogy elég jó ötletet kapjon az SQL Server teljesítményét érintő legfontosabb hardverproblémákról.

Ideális esetben a Performance Monitor használatával hozzon létre egy kulcsmérő leolvasási fájlt egy 24 órán át. Meg kell választania egy "tipikus" 24 órás időszakot a regisztrációs fájl létrehozásához. Például válasszon egy tipikus munkanapot, nem pedig a hét végét vagy nyaralását.

Amint a teljesítményfigyelő adatait 24 órán belül rögzítette a regisztrációs fájlban, megjelenítse az ajánlott métert a Teljesítményfigyelő grafikon módban, majd írja le az átlagos, minimális és maximális értékeket a fenti táblázatban. Miután megtette, hasonlítsa össze az eredményeket a következő elemzés eredményeivel. Ez az összehasonlítás lehetőséget ad arra, hogy meghatározza az SQL-kiszolgálót befolyásoló hardverek esetleges szűk keresztmetszeteit.

Hogyan kell értelmezni a kulcsfontosságú teljesítményfigyelő számlálókat

A következőket néhány alapvető teljesítményfigyelő számlálók, ajánlott értékek és egyes lehetőségek megvitatják, amelyek segítenek a hardverproblémák azonosításában és megoldásában. Meg kell jegyezni, hogy korlátozom a vizsgált teljesítményfigyelő számlálók számát. Ez azért történik, mert e cikk célja, hogy felfedezzék a teljesítményveszteség egyszerű és nyilvánvaló problémáit. A sok más teljesítményfigyelő számláló megvitatása máshol megtalálható ezen a weboldalon.

Memória: Oldalak / másodperc

Ez a mérő méri a másodpercenkénti oldalak számát, amelyek visszaállnak a RAM-ból a lemezre, vagy a lemezről olvashatók. Minél intenzívebb oldalak, az I / O műveletek nagyobb terhelése tapasztalható a kiszolgáló, amely viszont hátrányosan befolyásolhatja az SQL Server teljesítményét. A cél az, hogy megpróbálja csökkenteni az oldalakat minimálisra, anélkül, hogy megszüntetné.

A feltételezés alatt, hogy az SQL Server az egyetlen fő alkalmazás, amely a kiszolgálón fut, ez a számnak ideális esetben nulla és 20 közötti időközönként kell lennie. Nagyon valószínű, hogy a kibocsátás szignifikánsan meghaladja a 20, ami elég normális. A legfontosabb dolog az, hogy az átlagos oldal megosztását másodpercenként 20-nál tartsuk fenn.

Ha a szerver átlagosan több mint 20 oldalt mutat, másodpercenként, az egyik legvalószínűbb oka annak, hogy hiányzik a szükséges RAM. Általánosságban elmondható, hogy a több RAM-tétel az, annál kisebb az oldalak cseréje műveletei.

A legtöbb esetben az SQL Server alatt specializálódott fizikai kiszolgálón, megfelelő mennyiségű RAM-val, az átlagos oldal megosztási értéke kevesebb lesz 20. Megfelelő számú RAM az SQL Server számára a következő kritériumnak megfelelően definiálható: a kiszolgáló sikeres együtthatóval kell rendelkeznie a puffer gyorsítótárral (puffer-hit gyorsítótár aránya) 99% -kal. Ezt a mérőt az alábbiakban ismertetjük. Ha rendelkezik SQL Serverrel, amely 24 órán belül 99% -os vagy annál nagyobb értékkel rendelkezik, de az átlagos oldalt több mint 20-nál is megosztja ugyanazon az időtartam alatt, jelezheti, hogy fut és mások. Alkalmazások a fizikai Szerver SQL Server mellett. Ha ez a helyzet, akkor ideális esetben távolítsa el ezeket az alkalmazásokat, lehetővé tegye az SQL Server számára, hogy az egyetlen fő alkalmazás a fizikai kiszolgálón.

Ha az SQL Server nem végez más alkalmazást, és az oldalak cseréje átlagosan 24 órán belül meghaladja a 20-at, ez azt jelentheti, hogy megváltoztatta az SQL Server memória beállításait. Az SQL kiszolgálót úgy kell beállítani, hogy az "dinamikusan konfigurálja az SQL Server memória" opciót (dinamikusan konfigurálja az SQL Server memóriát), és a maximális memória telepítésének a legnagyobb értékben kell lennie. Az optimális munkához az SQL Servernek megengedett, hogy annyi RAM-t kell bevenni, mivel saját igényeihez szükséges, anélkül, hogy a gyors memóriákra szükséged van más alkalmazásokkal.

Memória: rendelkezésre álló hely

Egy másik módja annak, hogy megtudja, hogy az SQL Server elég fizikai memóriával rendelkezik-e, az, hogy ellenőrizze a memória objektumot: Elérhető bájtok. Értékének több mint 5 MB. Ellenkező esetben az SQL Server nagyobb számú fizikai memóriát igényel. Az SQL Server-ben szakosodott kiszolgálón az utóbbi 4-10 MB ingyenes fizikai memóriából próbál tartani. A fennmaradó fizikai ramot az operációs rendszer és az SQL szerver használja. Ha a rendelkezésre álló memória mennyisége közel 5 MB-ig vagy alacsonyabb, akkor valószínűleg az SQL szerver túlterhelést tapasztal a memória hiánya miatt. Ha ez a helyzet, meg kell növelnie a szerver fizikai RAM számát, csökkenteni kell a szerver terhelését, vagy módosítsa az SQL szerver memória konfigurációjának konfigurálásához szükséges beállításokat.

Fizikai lemez: Lemezidő

Ez a számláló azt mutatja, hogy a fizikai lemez tömb (nem logikai szakasz vagy külön lemez a tömbben). Jó relatív mérést biztosít, hogy mennyire elfoglalt a lemez tömbjei.

Empirikus szabályként a lemezidős számlálónak kevesebb, mint 55% -ot kell mutatnia. Ha a mérőolvasások a folyamatos időszakok alatt 55% -ot meghaladnak (több mint 10 perc a 24 órás megfigyeléshez), akkor az SQL Server problémákat okozhat az I / O műveletekkel. Ha ezt a viselkedést csak alkalmanként nézed a 24 órás megfigyelés során, nem aggódnék túl sokat, de ha gyakran történt (mondjuk, néhányszor óránként), elkezdtem keresni az I / O Műveletek a kiszolgálón vagy csökkentse a kiszolgáló betöltését. Néhány módszer a lemezbevitel / kimenet növelésére szolgáló módszerek, amelyek új lemezeket adnak hozzá egy tömbbe (ha lehetséges), a lemezek gyorsabbá tétele, gyorsítótár hozzáadása a vezérlőlapon (ha lehetséges), különböző verziók segítségével a RAID vagy a gyorsabb vezérlő telepítése.

Mielőtt ezt a mérőt NT 4.0 alatt használja, manuálisan engedélyeznie kell azt a következőkbe való belépéssel: "Diskperf-y" parancssorban. Ezt követően újra kell indítania a kiszolgálót. Így azonnal meg kell adnia a lemezszámlálókat a Windows NT 4.0 alatt. Ha Windows 2000 alatt működik, akkor ez a mérő alapértelmezés szerint engedélyezve van.

Fizikai lemez: a lemez sorának átlagos hossza

A mérő értékének megfigyelése mellett a "fizikai lemez: lemez működési ideje" is kívánatos a lemez sorának középső hosszának (AVG. Lemez sor hossza) értékének ellenőrzése. Ha ez az érték meghaladja a 2 értéket a folyamatos ideig (10 perc alatt alatt 24 órás felügyelet) minden meghajtó a tömbben, akkor ez a tömb is kiderülhet, hogy a szűk keresztmetszet a rendszer teljesítményét. Mint egy meghajtó időszámláló, ha ez esetenként 24 órás megfigyelési időszakban fordul elő, nem sokat aggódnék, de ha gyakran történik, akkor elkezdem keresni a szerver bemeneti / kimeneti rendszer teljesítményének növelését felett.

Ezt a mutatót kiszámítania kell, mivel a teljesítmény monitor nem tudja, hogy hány fizikai lemez van a tömbben. Ha például 6 fizikai lemezen van, és az átlagos várólem hossza 10 a tömb esetében 10, akkor az egyes lemezekre vonatkozó lemez sorának tényleges átlagos értéke 1,66 (10/6 \u003d 1,66), ami jól illeszkedik az ajánlott mutató 2 egy fizikai lemezenként.

Mielőtt ezt a mérőt használná az NT 4.0 alatt, ne felejtse el manuálisan bekapcsolni, írja be a meghívást az NT parancsokba való belépéshez, a következő: "Diskperf-y" a kiszolgáló későbbi újraindításával. Ezért a Windows NT 4.0 telepítése után azonnal meg kell adnia a lemezszámlálókat. Ha Windows 2000-et használ, akkor ez a mérő alapértelmezés szerint engedélyezve lesz.

Használja mind a fent leírt mérőt, hogy megtudja, hogy a szerver problémákat tapasztal-e az I / O rendszerrel. Ha például sok olyan időszakot lát, amikor a merevlemez több mint 55%, és ha az átlagos lemez sora hossza több mint 2 fizikai lemezen, akkor biztos lehet benne, hogy a kiszolgáló problémái vannak a bemeneti rendszerrel.

Processzor: Processzor idő%

Processzor objektum:% processzor időmérő áll rendelkezésre minden központi processzor számára, és értékeli az egyes CPU használatát. Hasonló mérő is rendelkezésre áll a központi processzorok teljes egészében (összesen). Ez egy kulcsmérő a központi processzor használatának nyomon követésére. Ha a teljes processzor betöltési ideje ezen a mérőnél meghaladja a 80% -ot a folyamatos időszakokban (10 percen keresztül 24 óra monitoring), akkor figyelembe veheti a központi processzort egy keskeny rendszerrel. Ha ezek az erős terhelés időtartama alkalmanként előfordul, és úgy gondolja, hogy elfogadhatja, akkor minden rendben van. De ha gyakran fordulnak elő, akkor fontolja meg, hogy az ilyen lehetőségeket a szerver betöltésének csökkentésére, a gyorsabb központi feldolgozók megszerzésének, a több központi processzorok beszerzésének, vagy a központi feldolgozók megszerzésének, amelyek nagyobb beépített másodlagos gyorsítótárral rendelkeznek ( L2).

Rendszer: processzor sor hossza

A processzor időszámlálóval együtt ellenőriznie kell a processzor sorhossz számlálót (processzor sor hossza) is. Ha ez a jelző a folyamatos időszakokban meghaladja a 2-es központi processzor értékét (10 perc alatt a 24 órás megfigyelési időszak alatt), akkor valószínű, hogy ez a rendszer keskeny rendszere. Például, ha 4 központi processzor van a szerveren, a processzor sor hossza nem haladhatja meg a teljes értéket 8.

Ha a processzor sor hossza rendszeresen meghaladja az ajánlott maximumot, de a központi processzor használata nem olyan magas (ami tipikus eset), akkor fontolja meg az SQL Server "Max Workerscents" konfigurációs paraméter értékének csökkentését ( a szálak maximális száma). A processzor sorának nagy értékének lehetséges oka a túlzott számú munkavállaló jelenléte, akik várják a sorát. A paraméterrel végzett számuk csökkentésével arra kényszeríti a szálak törzseit (ha nem történik meg), vagy növeli szerepét.

Használja mindkét leírt métert, hogy pontosan megállapítsák, hogy vannak-e problémák a központi processzorral. Ha mindkét mutató meghaladja az ajánlott értékeket ugyanolyan folyamatos idő alatt, akkor biztos lehet benne, hogy a központi processzor gyenge pont a rendszer.

SQL Server puffer: sikeres hozzáférési együttható a puffer gyorsítótárához

Ez a mérő (SQL Server puffer: puffer cache hit aránya) azt mutatja, hogy az SQL Server milyen gyakran utal a pufferre, és nem a merevlemezre, hogy megkapja az adatokat. Az OLTP alkalmazásokban ez az együtthatónak meg kell haladnia a 90% -ot, és ideális esetben 99% felett van. Ha a sikeres érintkezési együttható a puffer gyorsítótárral 90% alatt van, akkor menjen és vásároljon még több RAM-t ma. Ha ez az együttható 90% és 99% közötti tartományban van, akkor komolyan fontolóra kell vennie a további RAM vásárlási lehetőségét, mivel a közelebb megközelíthető 99% -kal, annál gyorsabban fog működni az SQL szerver. Bizonyos esetekben, ha az adatbázis nagyon nagy, akkor nem lesz képes közelebb kerülni 99% -kal, még akkor is, ha a kiszolgáló maximális megengedett számát helyezi el. Akkor minden, amit tehetsz, add hozzá a memóriát a maximumhoz, és elfogadja a dolgok meglévő helyzetét.

Az OLAP alkalmazásokban az együttható sokkal kisebb lehet az OLAP alkalmazás jellege miatt. Mindenesetre a RAM növekedése fel kell gyorsítani az SQL szerver működését.

SQL Server: Egyéni kapcsolatok

Mivel az SQL Server felhasználóinak száma befolyásolja teljesítményét, ajánlott az egyéni kapcsolatok felügyelete (SQL Server Általános statisztikai objektum: Felhasználói kapcsolatok számláló). Megmutatja a felhasználói kapcsolatok számát, és nem az SQL Serverhez csatlakoztatott felhasználók számát.

Ha a számláló leolvasásai meghaladják a 255-et, akkor növelnie kell a "maximális munkaterületek" konfigurációs paraméterének értékét (maximális munkatérek száma), amelynek alapértelmezett értéke 255. Ha a kapcsolatok száma meghaladja a meglévő számát Munka szálak, az SQL Server elkezdi megosztani a munkaterületek megosztását, ami hátrányosan befolyásolhatja a teljesítményt. A paraméter beállítása magasabbnak kell lennie, mint a kiszolgálón elérhető csatlakozások maximális száma.

Mi a következő lépés

Bár sokkal nagyobb számú számláló van, mint amennyit figyelembe vettünk, az utóbbiak kulcsfontosságúak a megfigyeléshez, amelyet az ellenőrzési teljesítmény folyamatában végzik. A teljesítményfigyelő elemzés befejezése után használja az ajánlásokat, majd ebben a cikksorozatban a szükséges változtatásokat, amelyek az SQL Server működésének meg kell működniük.

Bármely adatbázis adminisztrátor, gondoskodnia kellett azzal, hogy minden lassan működik, vagy egyáltalán nem működik. Az első dolog, amit meg kell találnod, az, hogy jelenleg az SQL Serveren jelenleg történik. Úgy tűnik, hogy az adminisztrátor arzenálja az összes hasznos darabot: egy BUVA tevékenységfigyelő, egy csomó dinamikus menedzsment nézet (DMV), SP_WHO és SP_WHO2 tárolt eljárások, amelyek az SQL Server 7 és az SQL Server 2000 óta örököltek.
De lássuk ...

Monitoring eszközök

Tevékenységi monitor

Úgy tűnik, nagyszerű dolog, hogy részt vesz azzal, hogy szükséges - a tevékenységet figyelemmel kísérik. Nehéz számviteli jelentést indítok, és megnézem, hogy melyik tevékenységfigyelő mutasson meg nekem.
A SCREENSHOTS TEVÉKLET MONITOR Az SQL SERVER 2005-től:

és az SQL Server Denali (2012) CTP 3.


M-igen. És ha egy tucat ember elindítja az ilyen jelentéseket? És ez nem ritka ... meglehetősen kényelmetlen lesz, bár természetesen az arcra halad. A Denali aktivitási monitoron sokkal hasznosabb információt mutat (például az erőforrás-elvárás során), plusz, például a kívánt munkamenethez, futtathatunk egy profileret közvetlenül a monitorból, és nyomon követhetjük már a Profiler, de károsítja, továbbá betölti és betölti a betöltött kiszolgálót. Ezenkívül már van probléma a fékekkel, és azok a kérések, hogy a profilok elindításakor már elkezdték végrehajtani, nem fogjuk látni.
És ezt szeretném látni - ki és mit csinál most.

sP_WHO és SP_WHO2.

A képernyőképen az SP_WHO (felülről) és a SP_WHO2 (alsó) végrehajtásának eredménye a teljes rosszindulatú jelentés építése során:


Igen. Nagyon informatív. A SP_WHO-ra nézve csak azt láthatjuk, hogy mi működik. Természetesen azt hajtják végre - mi vagyunk, és látjuk, és látjuk, hogy bizonyos választás történik. Vagy néhány közül választhat "ov. Nagyszerű.
sP_WHO2 További információkat jelenít meg. Most láthatjuk, hogy mennyi processzor időt töltött az ülésen (és az oszlop teljes időtartamát, látszólag), az I / O műveletek számát, az adatbázis nevét, amelyben mindezt végrehajtják, és akiket ez a munkamenet blokkolja ( Ha blokkolva van).
Tevékenységi monitor, amint azt látjuk, több információt ad.

Dmv

Az SQL Server 2005-el kezdődően új lehetőséget kaptunk a szerver állapotáról - dinamikus menedzsment nézetekről. Az MSDN azt mondja: "Dinamikus adminisztratív ábrázolások és funkciók A kiszolgálói állapotadatok visszaadása a kiszolgáló példányának ellenőrzésére, a probléma diagnosztikájának és teljesítménybeállításainak ellenőrzésére."
És valójában a 2005-ös SQL Server "E Van egy nézet, amely a jelenlegi pillanatban a kérelmek végrehajtásával kapcsolatos (azonban a" történelem "megtekintéséhez is előadások vannak): Itt vannak. És a számuk A verzió verziója továbbra is növekszik!
Bizonyára a Mastic adminisztrátorok sok szkriptel rendelkeznek, így információt kaphat a szerver aktuális állapotáról, de mit kell tennie, ha a DMV-vel való munkavégzés tapasztalata még nem, de már vannak problémák?

sp_whoisaktív

Adam Machanic (SQL Server MVP és MCITP) kifejlesztette és folyamatosan szerényíti a SP_WHOOISACTION tárolt eljárást, amely csak ezeken a legtöbb DMV és a rohadt könnyen használható. Töltse le a SP_WHOISACTION legújabb verzióját. Ádámban van egy sor cikk, amelynek sp_whoisaktív, 30 (harminc!) Darabból áll, olvashatod, és megpróbálom érdeklődni az anyag olvasásában :).
Tehát feltételezzük, hogy letöltötte és elindította ezt a szkriptet az egyik tesztszerveren (2005-től kezdve bármely verzión, és Denalivel végződik). Ádám azt tanácsolja, hogy tárolja a Master System adatbázisban, hogy bármely adatbázis kontextusában lehessen hívni, de nem szükséges, ha egy másik adatbázis összefüggésében hívja fel, akkor a nevet teljesen meg kell írnia a nevet. sham.sp_whoisactive.
Tehát próbáld meg. A képernyőképen, annak végrehajtásának eredménye az egész azonos jelentés építése során:

A EXEC SP_WHOISAKECTIVE, az ALAS, nem létezik egy képernyőn, így a paraméterek nélküli tárolt eljárás kimenetének szöveges leírása.

• - Aktív kérésre, megmutatja a végrehajtás idejét, az "alvás" munkamenethez - az "alvás" idő;
• - valójában, Spid;
• - Megmutatja a jelenleg végrehajtott szöveget, vagy az utolsó végrehajtott lekérdezés szövegét, ha a munkamenet alszik;
• - Nos, megértetted;
• - Nagyon érdekes oszlop. Megjelenik a formátumban (AX: BMS / CMS / DMS) E. A az E. b / c / d erőforrás várakozási feladatainak száma - ez várakozási idő milliszekundumban. Ha az erőforrás csak egy munkamenetet vár (mint a screenshot), várakozási ideje megjelenik, ha 2 munkamenet a várakozási időtartama B / C formátumban. Ha 3 vagy annál többet vársz - a B / C / D formátumban a minimális, átlagos és maximális várakozási időt fogjuk látni;
• - Az aktív vizsgálathoz - a CPU teljes időpontja, amelyet ebben a kérelemben töltöttek, az alvási munkamenethez - a CPU teljes időpontja az ülésszak "egész életében";
• - Aktív lekérdezés esetén ez a lekérdezés végrehajtása során a TEMPDB rögzítési műveleteinek száma; Alvási munkamenethez - a TEMPDB-ben lévő bejegyzések száma az ülés minden életében;
• - aktív lekérdezéshez - a kéréshez rendelt TempdB oldalak száma; Az alvási munkamenethez - az ülés teljes élettartamához rendelt TempdB oldalak száma;
• - Ha hirtelen blokkolja valakit, Spid (Session_ID) megmutatja, hogy ki blokkoltunk;
• - aktív lekérdezéshez - a kérés végrehajtásakor végrehajtott logikai leolvasások száma; Az alvási munkamenethez - az olvasási oldalak száma az ülés minden élettartamához;
• - ugyanaz, de a rekordról;
• - aktív lekérdezés esetén - a kérés végrehajtása során végrehajtott fizikai leolvasások száma; Az alvási munkamenethez - hagyományosan az ülés teljes élettartamának fizikai méréseinek teljes száma;
• - egy aktív lekérdezéshez - a kérés végrehajtásában használt nyolc kilobyt oldalak száma; Az alvási munkamenethez - hány perc memóriaoldalt emeltek ki minden életében;
• - a munkamenet állapota végrehajtásra kerül, alszik stb.;
• - megmutatja a nyitott munkamenet tranzakcióinak számát;
• - Megmutatja, hogy van-e ilyen lehetőség, az üzemeltetési folyamat (például biztonsági mentés, visszaállítás), soha ne mutassa meg, hogy a kiválasztás mennyi százaléka van végrehajtva.

A fennmaradó oszlopok B. szabvány kimenet SP_WHOISACTICE érdekesnek tűnik, és nem fogom leírni őket - a céljukat, azt hiszem, mindenki számára érthető (Host_Name, Database_Name, Program_Name, Start_Time, Login_Time, Request_ID, Collection_Time).

És akkor? Ez minden?

Nem, ez nem minden. Azt is elmondom, hogy mit (a legérdekesebb és hasznos, az én szempontból) paraméterek lehetnek SP_WHOISACTIKA, és mi fog működni.

• @help szörnyű hasznos paraméter. A SP_WHOISACTIONE @HELP \u003d 1 hívásakor információkat kapunk a képernyő összes paraméteréről és kimeneti oszlopáról. Tehát, ha valami nem érhető el, akkor mindig láthatja a "súgót"
• @Filter_type és @Filter - Engedje meg, hogy szűrje a végrehajtás eredményét. @Filter_type elfogadhatja a "Session", "Program", "Adatbázis", "Bejelentkezés" és "Host" elfogadását. A @Filter paraméterben megadjuk a kiválasztott típusú típusú érdekeket. Például szeretnénk látni a Master adatbázisban futó összes munkamenetet, ezért hívjuk a SP_WHOISACTION @FILTER_TYPE \u003d "DATABASE", @FILTER \u003d "MASTER" gombot. A @Filter paraméter megengedhető a "%" használatára;
• @not_filter_type és @not_filter - Engedélyezzünk, hogy "ellenkezőleg" legyen ". Azok. Például szeretnénk látni mindent, kivéve azokat a munkameneteket, amelyek az "adatbázis" mezőben "Master", Ehhez végrehajtja a EXEC SP_WHOISACTION @NOT_FILTER_TYPE \u003d "DATABASE", @NOT_FILTER \u003d "MASTER". Nos, vagy szeretnénk látni, hogy az összes felhasználó, kivéve a user sa ... alkalmazások beállíthatók. A @not_filter paraméter megengedett a "%" használatára;
• @show_system_spids \u003d 1 - megmutatja a rendszer ülésszakáról szóló információkat;
• @Get_full_inner_text \u003d 1 - Az SQL_Text mezőben nem csak az aktuális kérés szövege (stetiment) a csomagban (batche), és a teljes adagoló szövege teljes egészében;
• @Get_plans - Add hozzá a kimeneti oszlophoz lekérdezési végrehajtási tervekkel;
• @Get_transaction_info \u003d 1 - Hozzáadja a nyilvántartások kimenetét és mennyiségét a tranzakciós naplókhoz, valamint az utolsó tranzakció megkezdéséhez;
• @Get_locks \u003d 1 - hozzáteszi a kimeneti információkat a lekérdezés végrehajtása során kivetett zárakról;
• @find_block_leaders \u003d 1 - követi a zárláncot, és megmutatja az aktuális munkamenet felszabadítására váró munkamenetek teljes számát;
• @Output_column_list \u003d "[%]" - Mi van, ha nem szeretné látni a tempdb információit a SP_WHOISACTICE kimenetében? Ezzel a paraméterrel ellenőrizheti azt a tényt, hogy megjeleníti;
• @Destination_table \u003d "table_name" - megpróbálja beilleszteni a végrehajtás eredményét, hogy írjon az asztalra, de ez a táblázat nem ellenőrzi, hogy elegendő-e behelyezni.

Most mindenki

Ennek eredményeképpen van egy másik rendkívül kényelmes és rugalmas eszközünk az aktuális aktivitás nyomon követésére az SQL Serveren. Normál működéséhez elegendő a View Server állam megoldása és a DMV felkérésének jogai.
Azt is érdemes hozzáadni, abban az esetben, ha csak a szerverhez csatlakoztatható

Ez a szoftver termék Sybase, dolgozik az SQL Serverrel, és különböző információkat ad ki a szerver teljesítményéről grafikus formában. Ez az információ kivételesen hasznos a teljesítmény csökkentésének okainak elemzése során.

a 11.0.1-es verzió számos olyan új fontos lehetőséggel rendelkezik, amelyek jelentősen megkülönböztetik az új verziót az összes korábbiból. A 11.0.1 az SQL Server bármely verziójával működik, a 4.9.2 és a végződő rendszer 11.

Az adatbázis-objektumok használatának természetétől számított legérdekesebb információkat azonban csak akkor adják ki, ha az SQL Server System 10 és a 11 rendszert felügyelik. Természetesen a megnevezett gyorsítótár pufferek működésének adatai csak az SQL Server System teljesítményének ellenőrzése esetén kerül kiadásra.

A korábbi verziókkal való kompatibilitás érdekében a 11.0.1 támogatja a szerver teljesítményéről szóló statisztikai információk kiadásának módját is, amelyek a későbbi összehasonlításhoz és elemzéshez használhatók. Ez a lehetőség nagyon hasznos a gyakorlatban, de a használat bonyolítja a telepítési folyamatot.

két komponensből áll: egy SQL Server egy gépen futó kiszolgálómodul, amely hozzáférést biztosít a megosztott kiszolgáló memória területéhez, és egy olyan ügyfélmodul, amely képes bármely számítógépen dolgozni. Az ügyfélmodul fő feladata a kiszolgálómodul által felhalmozott információk olvasása, valamint a felhasználó által grafikus formában történő bemutatása.

A kezeléskor meg kell szüntetnie a DBCC Memusage parancs által végzett kiszolgáló memóriaellenőrzést, mivel ez a parancs jelentősen lelassítja a kiszolgáló működését. Ehhez az SQLMON (ügyfélmodul) indításakor meg kell adnia a NOMEM paramétert.

Az alapértelmezett konfiguráció egyidejű kapcsolatot biztosít öt kliens modulhoz egy kiszolgálómodulhoz. Más szóval, egy kiszolgálómodulhoz vagy öt kliens modulhoz csatlakozhat egy ablakon, vagy egy öt nyitott ablakkal rendelkező ügyféllel.

A kiszolgálómodul elindításakor ugyanabban az időben a nyitott ügyfelek maximális száma van telepítve.

Így a kiszolgálómodul parancsnoki fájljának 20 ablakának támogatásához meg kell adnia a P2 paramétert 0. Ezzel a beépített szerver memória területének címére van szükség a BuildMaster parancs és más műveletek használatával. Ezeket a műveleteket nem lehet végrehajtani az SQL Server működés során. (Részletek az egyidejűleg támogatott ügyfelek számának bővítésének folyamatáról, lásd a kiszolgáló kiegészítő szerver modul kézikönyvét.)

van néhány hátránya. Például egy oszlopdiagram, amely bemutatja az I / O műveletek számát és a kiszolgálóeszközök egyéb jellemzőit, amely egyszerre csak korlátozott eszközszámot jelent.

Ez kényelmetlen, ha egy nagy szerver nagyszámú kiszolgálóeszközt figyel. Ezenkívül a felhasználó nem választhatja ki az eszközöket, amelyen a diagramban szerepel, valamint a különböző eszközök közötti kapcsolódást.

A szöveges tábla egyidejűleg jelenik meg a képernyőn a diagram segítségével az összes kiszolgáló eszköz listáját tartalmazza, de csak az egyes I / O műveletek számát tartalmazza. Ez különösen nehezen dolgozik egy nagy szerverrel, amelyen számos kiszolgáló eszközt támogatnak a felhasználói adatbázis-szegmensek támogatására a teljesítmény növelése érdekében. Ebben az esetben az összes rendelkezésre álló szegmens munkájának elemzése lehetetlen.

hosszú ideig nem teszi lehetővé a teljesítménymutatók változásainak dinamikáját.

Képes adatokat küldeni a képernyőn 60 egymást követő teljesítménymérési időközönként. Az egyes intervallum kiválasztott időtartamától függően az ilyen statisztikák meglehetősen nagy ideig fedezhetnek. Ez a recepció azonban nem teszi lehetővé a jelenlegi adatokat havi vagy éves korlátozásokkal való összehasonlításához.

Természetesen a programablakok képei kiállíthatók a nyomtatónak, de akkor a fájlkészleteket vagy a hegyi kinyomtatást kell tárolniuk a jövő szerver teljesítményének értékeléséhez. A gyakorlatban a szerver adminisztrátornak gyakran meg kell vizsgálnia a vállalat üzleti ciklusának különböző időszakaiban kapott adatokat, valamint összehasonlítani a soros üzleti ciklusok azonos időszakait, hogy megkapja a szerver valós teljesítményét .

Mivel az elindítás egyetlen szerver lassulásához vezet, a mérések megkezdése előtt meg kell határozni a lassulás értékét egy adott hardver- és szoftverplatformhoz. A jó mérési módszer egy szabványos vizsgálati ügyletek végrehajtása.

Mind a kiszolgálógép jelenlétében, mind távollétében használható. Még ha nincs kliens modul, a programkiszolgáló modul folytatja működését, és egy külön parancsot kell leállítani.

lehetővé teszi, hogy készítsen több, különböző grafikai ablak a képernyőn, amelyek mindegyike tartalmaz információkat egy adott szempontból a szerver működését.

Főablak (főablak)
A program által támogatott Windows listát tartalmazza. Abban az esetben, ha a Sglmon-kliens modul elindul, a NOMEM paraméter nincs megadva, a kiszolgálógép memóriájának áramköri ábrája ebben az ablakban is ki van adva.

Cache pufferek (gyorsítótár)
Ebben az ablakban grafikonokat adnak ki, jellemzik az eljárások és adatok gyorsítótárpufferek munkáját. Az adatpuffer fizikai és logikai I / O műveleteinek számának ellenőrzésével a felhasználó meghatározhatja, hogy az adatok melyik része az adatlapokhoz a pufferben már elhelyezett oldalak segítségével történik. Az adatpuffer és az eljárási puffer által előállított ilyen statisztikák lehetővé teszik a kiszolgálói gyorsítótáros pufferek által megkövetelt memória teljes mennyiségének meghatározását, valamint az adatpufferek és eljárások közötti arányt.

Cache puffer adatok csak az SQL Server System 11-hez (adat Cach)
Az ablak beszámol a szerveren konfigurált nevű cache pufferek fizikai és logikai I / O műveleteinek számáról.

Lemezbevitel / kimenet (I / O eszköz)
Íme a grafikák és az összefoglaló táblázatok az aktuális és a teljes számú fellebbezést a lemezekre. Segítenek optimalizálni az I / O terheléselosztást az elérhető szervereszközök között. Elemzésekor kiadott információ, érdemes használni a standard diagramja adja meg a nevét kiszolgáló eszközök nevek a megfelelő partíciók fizikai lemezek, mert azáltal, hogy az árfolyam-kiszolgáló eszközök, tudnia kell, hogy az egyes ilyen eszközök csatlakoztatva, hogy melyik lemezvezérlőre van szükség.

Munka a hálózathoz, csak az SQL Server System 10 és 11 (hálózati tevékenység) esetén
Az ablakot a hálózati bejegyzésről szóló statisztikai információkra jelentik "kimenet - a csomagok mérete, a forgalom mennyisége stb.

A 10 és 11 SQL Server System objektumokhoz való hozzáférés zárása (objektumzár állapot)
Ez a rész információkat blokkoló adatok adattáblák, beleértve a részletes elosztása a típusú használt zár, a nevét a folyamatokat, amelyek a zárat, stb

Az objektum oldalak bevezetése csak az SQL Server System 10 és 11 (Object Page I / O)
Az ablak tartalmazza az I / O portjainak intenzitását az egyik kiszolgáló adatasztala. Figyeljen arra, hogy a leggyakrabban használt kiszolgáló táblázatok listájának kidolgozása. Az ilyen információkat az SP_SYSMON eljárás nem adja ki.

Teljesítmény Summar (teljesítmény)
Itt egy általános kép az SQL Server funkció kerül bemutatásra - a százalékos processzor időt mutatja, az összeg a tranzakció feldolgozása másodpercenként, az összeget a hálózati forgalom, a lemez I / O, valamint az intenzitása a használatát zárak .

A teljesítménymutatók dinamikája (teljesítmény trend)
A teljesítmény-összefoglaló ablakban kiadott időbeli korlátozások folyamatos grafikonjai az ablakban vannak kialakítva.

Szerver folyamat aktivitása (folyamat aktivitása)
Az ablak lehetővé teszi, hogy válasszon egy vagy több kiszolgáló folyamatot, és kövesse a feldolgozó és az I / O kötetek használatát az egyes folyamatokhoz.

Részletes folyamat részletek (folyamat részletek)
Az ablak részletes információkat tartalmaz a kiválasztott kiszolgálófolyamatról.

Folyamatlista (folyamatlista)
Az ablak tartalmazza az aktuálisan elérhető kiszolgálói folyamatok listáját, amelyek jelzik az állapotát. Nagyon hasonlít a SP_WHO SERVER parancs kiadásához.

Zárak használata (folyamatzár tevékenység)
Az ablak problémái az Ön által kiválasztott kiszolgálói folyamat használatával kapcsolatos információkat.

A tárolt eljárások (tárolt eljárási tevékenység) használata
Az ablak tartalmaz információkat a tárolt eljárások végrehajtásáról és az egyes eljárások működési idejéről.

Tranzakciós tranzakció (tranzakciós tevékenység)
Az ablakban láthatunk egy oszlopdiagramot, amely bemutatja a tranzakciók feldolgozásának mennyiségét különböző típusú tranzakciók alapján. Láthatja például, hogy a tranzakciók milyen része lehet a webhely frissítési mechanizmusával (frissítés a helyén).

12.26.2006 Kevin Kine

Milyen kérdést szeretne kapni az adatbázis adminisztrátora? Valószínűleg egy üzenet a felhasználóról az alkalmazás romlásáról vagy az adatbázissal történt kérdésről. Szükséges, hogy elhalasztani az összes esetet, és menjen a "vészhelyzeti módba", találgatás, hogy hosszú ideig. Mivel az adatbázis-adminisztrátor egyik fő feladata az ipari adatbázisok minőségi működésének biztosítása, csak a meghibásodás gyors megszüntetése. Ideje, hogy megtudja a kudarc okát, általában nem.

Több AVRALS - csak szisztematikus megfigyelés

De ez az egyetlen dolog, amit lehet tenni? A proaktív teljesítményellenőrzést, egy egyszerű kezelési eljárást végezhet, amely a rendszer alapvető paramétereinek meghatározását használja, a szabványok fogadását és folyamatos megfigyelését. Ebben a cikkben elmondom, hogyan kell alkalmazni a proaktív megfigyelést, és hogyan hozhat létre ingyenes vezérlési rendszert a Windows rendszer monitor segítségével.

Proaktív megfigyelés

A Proaktív teljesítményfigyelés egy egyszerű rendszer, amely lehetővé teszi a problémák megoldását, mielőtt kritikusak lesznek. Valaki valószínűleg már kivételes helyzetek megfigyelését használja, amikor az automatizált folyamatok létrejöttek, amely csak a normától eltérő eltéréseket észlel, de nem nyújt mély információt, és nem nyújt lehetőséget a problémák megelőzésére. Proaktív teljesítményfigyelés, éppen ellenkezőleg, biztosítja a felhasználót mindenféle információval a munkakörnyezetről és az alkalmazásokról, valamint a rövid távú és hosszú távon. Az adatbázis jellemzőinek számlálásainak olvasása eltávolításra kerül, a referenciaértékek be vannak állítva, és az aktív felügyeleti mód támogatott.

Mivel a név azt jelenti, a proaktív teljesítményfigyeléshez intézkedéseket igényel. Szükséges egy kis időt tölteni a telepítésre és egy kis időt arra, hogy megértsük az adatbázisok és alkalmazások működését. Annak érdekében, hogy a proaktív teljesítményfigyelés hatékony legyen, meg kell néznie az üzeneteket, így kiterjedt összegyűjtött adatokat használhat.

Alapvető paraméterek, szabványos, monitor

Kezdjük több feltétel meghatározásával. Alapvető paraméterek (alapvonal) - Ez egy olyan paraméterek sorozata, amely a kiszolgáló viselkedését és alkalmazásai normál körülmények között jelenít meg. Az alapvető paramétereket az azonos feltételek mellett végzett több mérés eredményeinek átlagaként kapják meg; Ezek referencia-iránymutatások.

Viszonyítási alap A rendszer teljesítményét a kiszolgálói terhelés bizonyos szintjén mutatja be, amely lehetővé teszi, hogy összehasonlítsa az ipari szerver teljesítményét egy ilyen szinten, és meghatározza a kiszolgáló mutatóit, hogy mennyire magasabbak a normák (azaz amikor a kiszolgáló rosszul működik). Az alapvető paraméterekhez hasonlóan a szabványok értékeit szabályozott környezetben távolítják el, a kulcsértékeket előre meghatározott mutatókkal kapcsolatban határozzák meg. Ha meg kell néznie, hogy a szerver és az alkalmazás hogyan viselkedik több szinten vagy letöltési típusnál, akkor több referenciaértéket általában kapunk (az alapparaméterek tekintetében).

Monitoring (monitoring) - Ez a valós idejű szerver ütemezett felügyelete előre meghatározott feltételek mellett (további kutatás vagy figyelmeztetések) meghatározott feltételek). Például, ha meg kell találnod, hogy mennyi időt vesz igénybe egy fontos üzleti alkalmazás jó végrehajtása, mennyi ideig tart a biztonsági mentés, és ha bizonyos teljesítményértékek érnek el, akkor figyeljük meg a megfigyelést.

Most foglalkozunk proaktív megfigyeléssel. Használhat harmadik féltől származó termékeket vagy szabad megoldást, amely rendszerfigyelőt használ. A harmadik féltől származó cégek döntései egyszerűsíthetik a proaktív megfigyelés beállítását, és olyan funkciókat tartalmazhatnak, amelyek szabadon beágyazott oldatot tudnak biztosítani. De mielőtt elkezdené, megmutatom, hogyan kell eljárni a proaktív megfigyelés végrehajtásához a rendszer monitor segítségével.

1. lépés: Határozza meg az alapvető teljesítményparamétereket.

Az első lépésben a proaktív megfigyelés ellenőrzési módjának biztosítása érdekében létrejön az adatbázis-kiszolgáló alapvető paramétereinek. Ez a készlet normál körülmények között a kiszolgáló teljesítményét jelzi, segít dokumentálni és megérteni az összes jelentős háttérfolyamatokat is, amelyek segítenek olyan helyzeteket jelölni, amelyek nem igényelnek beavatkozásokat annak érdekében, hogy ne figyeljenek rájuk. Más szavakkal, az adatbázis-adminisztrátorok meghatározhatják a rendszerüzenetek figyelmen kívül hagyására vonatkozó lehetőségeket, mivel egyébként nagyszámú hamis értesítések vannak kialakítva.

Annak érdekében, hogy vizuálisan megmutassák a működés minőségét, a legjobb alapvető paraméterek néhány grafikonokat használnak (ideális esetben egy), hogy első látásra láthassa, hogyan működik a szerver. Ha alapvető paramétereket definiálnak, akkor a következőket kell tennie. Először válasszon ki egy lehetőséget a teljesítményadatok mentéséhez a rendszernaplóban vagy a valós idejű kijelzőn. Ideális, hogy mindkét lehetőség közül rendelkezzen: a regisztrációs naplók lehetővé teszik, hogy bármikor visszatérjenek az olvasásokhoz, hogy elemezzék, milyen termelékenység volt a rendszer közvetlen nyomon követése. A valós idejű megfigyelés nem foglal munkát a lemez- és kiszolgáló erőforrásaiban, de megköveteli a figyelmeztetés 100 százalékos rendszerét. Másodszor, meg kell határozni az olyan intervallumot, amelyen keresztül a megfigyelés elvégezhető, tekintettel az adatgyűjtés és az I / O működés teljesítményének költségeit, és értékeli a kívánt tér költségeit. Minél nagyobb az intervallum, annál nagyobb a valószínűsége, hogy az Ön által érdekelt termelékenységi adatok nem kerülnek beszerelésre. Végül válasszon helyi vagy távfelügyeletet. A helyi felügyelet, amelyben az ellenőrzési folyamat ellenőrzött kiszolgálót használ, nem termelő költségeket ad a processzornak és a szerverlemeznek. A külön szervert használó távfelügyelet megszabadulhat az ilyen problémáktól, de ez nagymértékben növeli a hálózat munkaterhelését.

A felsorolt \u200b\u200brendszerfigyelő metrikákban vagy számlálókban, amelyeket ajánlott az alapvető paraméterek meghatározásához használni. Nem tudom megmondani, hogy mi az érték "helyes" egy külön alkalmazás keretében, mivel a rendszertől a rendszerig változik. A következő átlagos értéke különböző alapvető paraméterek telepíteni a szokásos szabvány (bázis paraméterek) teljesítményt és kijelöli, hogy ez az opció helyes az operációs rendszer.

Alapparaméterek meghatározása a rendszermonitor használatával

Most az alapvető paraméterek összegyűjtése érdekében hívja a rendszerfigyelőt. Nyílt kezelőpanel, adminisztrációs eszközök, teljesítmény. Kattintson duplán a teljesítménynaplókra és figyelmeztetésekre a bal oldali ablaktáblán. Nyomja meg a jobb oldali gombot az adatszámlákon, és adja meg az új napló beállításait. 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 műveleteket, amíg az összes számláló hozzáadódik, majd kattintson a Bezárás gombra.

Kezdje, próbálja meg az alapértelmezett 15 másodperces intervallumot. Vagy válasszon egy másik intervallum megnyomásával Tulajdonságok (vagy használja a gyorsbillentyű kártya Ctrl + Q), majd adja meg az értéket a feliratok a minta mindig automatikusan: _ másodperc. Hosszabb időközönként kevesebb helyet foglalnak el, de kevésbé részletes adatokat szolgáltatnak.

Válassza ki a naplófájl tábláját, és határozza meg a helyet, ahol az adatok tárolódnak. Lehetőség van az adatok későbbi megtekintésére a Nézet naplófájl-adatnézet használatával. A System Monitor a képernyőn megjelenik, ha összegyűjti az alapvető teljesítményparaméterek adatait. Látható, hogy a különböző mérők nyomon követése közben sok adatot gyűjthet, így gondosan válassza ki a fővonal méterét.

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

Az alapszerver teljesítményparaméterei után elkezdheti a referenciaértékek telepítését, ami megkönnyíti a szerver teljesítményét, ha több előre meghatározott helyzetben dolgozik.

A szabványok esetében ugyanazt az ellenőrzési módot használják az alapvető paraméterek meghatározásához. Használhatja a megoldás vagy egy közös ipari eszközök, mint például a TPC-C vagy az SAP, de a legjobb eredmény kiszámításának referencia értékeket kapunk, ha a fejlődő hagyományos egyes forgatókönyvek, amelyek úgy vannak kialakítva, hogy egy meghatározott adatbázis szerver és alkalmazásai.

Saját forgatókönyvet hozhat létre a T-SQL Script Set, OSQL segédprogramok vagy lekérdezési analizátor, SQL Profiler és System Monitor segítségével. A T-SQL terhelési vizsgálati forgatókönyvei általában több napot vesznek igénybe. Még több időre lehet szükség a terhelési vizsgálatok végrehajtásának és a kapott adatok elemzésének összegyűjtéséhez.

Miután meghatározta a szerver teljesítményének alapvető paramétereit előre meghatározott terhelésekkel, akkor lehet tudni, hogy mi várható a rendszerből. Használja az összegyűjtött adatokat a referenciaértékek fogadásakor a tervezett megfigyelés alapja. Például kiderült, hogy a kiszolgáló másodpercenként akár 249 tranzakciót is képes biztosítani, mielőtt a munkája lelassul. Ebben az esetben az alacsony prioritású értesítést telepíthet, ha a kiszolgáló eléri a letöltést körülbelül 200 TP-k és értesítés kiemelt fontosságú, ha a kiszolgáló eléri a 235 TPS-t. Ez a módszer lehetővé teszi az adminisztrátor számára, hogy megtudja a kiszolgálóval kapcsolatos lehetséges problémákat, és megtegye a szükséges intézkedéseket, mielőtt a felhasználók észrevesznek semmit. És nincs kritikus helyzetek. Most lehetséges.

3. lépés: Tervezett ellenőrzés

Talán a proaktív megfigyelési mód legfontosabb összetevője a tervezett megfigyelés. Ennek nélkül lehetetlen követni az adatbázis működését, vagy észleli a teljesítmény problémáit.

Létrehozhat egy olcsó eszközt az SQL Server felügyeletéhez az SQL Server Agent és a System Monitor kombinációjával. Az SQL Server Agent lehetővé teszi, hogy meghatározza, hogy mely esemény kimenete a monitorhoz, a beállítást, aki hibát kap az eseményekről, és automatikusan küld egy értesítést, ha hiba esemény jelenik meg.

Az SQL Server Agent telepítése hosszú idő lehet, és kihívást jelenthet, így szükség lesz az SQL Server riasztásainak leírás szakaszára Könyvek online (Bol). Az SQL Server Agent jellemzően az adatbázis-kiszolgáló működési hibaüzenetének aktuális ellenőrzését végzi, és nem irányítja a végrehajtást.

A rendszerfigyelőt a szerver teljesítményének figyelemmel kísérésére használják az aktuális mérők megfigyeléséhez (állítsa be a felmérési frekvenciát 15 percig).

Memória oldalak / sec

Hálózati interfész-bájtok teljes / sec

Fizikai lemez-lemez transzferek / sec

Processzor-% processzor idő

SQLSERVER: Hozzáférési módszerek - teljes vizsgálat / sec

SQLSERVER: pufferkezelő-puffer gyorsítótár hányada

SQLSERVER: Adatbázisok Alkalmazás adatbázis-tranzakciók / sec

SQLSERVER: Általános statisztikák-felhasználói körzetek

SQLSERVER: RATCHES-Átlagos retesz várakozási idő

SQLSERVER: Locks-Átlagos várakozási idő

SQLSERVER: LOCKS-LOCK TIMEOUTS / SEC

SQLSERVER: LOCKS-számú holtpontok / sec

SQLSERVER: A memóriakezelő-memória-támogatások függőben vannak

Állítsa be az egyes számlálók értékét az alapvető paraméterek értékei között, és a tesztelésben bemutatott referenciaértékek. 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 a figyelmeztető üzenetet 90 százalékot ad.

Figyelmeztetés elvégzéséhez olyan ingyenes eszközöket használhat, mint az SQL Server riasztások és értesítések, rendszerfigyelő vagy vásárlás a Microsoft Operations Manager (Anya) vagy más eszközökkel. Azt javaslom, hogy a figyelmeztetések legalább a következő helyzetekben:

• a működést befolyásoló hibák, különösen a 19-25-ig jelentőségű jelzővel rendelkező hibák
• zár
• a processzor használata
• használati lemez
• szkennelés (SQLSERVER: Hozzáférési módszerek)

Riasztásokat küldhet az adminisztrátorok értesítéséhez e-mail, pager vagy hálózaton keresztül. Automatizált figyelmeztetéseket telepíthet a következő üzenetekhez:

• sQL Server Journal
• sQL Agent Magazine
• windows, biztonság és rendszer
• job Execution Log SQL Server

Végül meg kell győződni arról, hogy saját fejlesztési alkalmazások helyesen regisztrálják a hibákat, és továbbá válaszolnak más fejlett alkalmazások hibaüzenetekre.

A Performance SQL Server proaktív megfigyelése az alapvető teljesítményparaméterek meghatározását jelenti mind a kiszolgáló, mind az alkalmazás esetében; A kiszolgáló működését szimuláló referenciaértékek telepítése az előre meghatározott forgatókönyv szerint, valamint az ütemezett megfigyelés végrehajtásával, ideális esetben figyelmeztetés kezdeményezése, amikor a problémát észleli. Függetlenül attól, hogy szabad vagy beépített eszközöket használnak vagy oldatok független cégeket választanak, a jelenléte a kontroll garantálja, hogy megkapja a szükséges információkat a művelet az alkalmazások a SQL Server a kívánt pillanatban.

1. táblázat: Objektumok és rendszerfigyelő mérők az alapvető paraméterek meghatározásához

Tárgy- és számláló	Leírás
Memória oldalak / sec	Az olvasási oldalak száma vagy a lemezre történő írásban. Ez a mérő a rendszerszintes késedelmek vagy teljesítményproblémák által okozott elsődleges hiba típusú indikátor
Hálózati interfész-bájtok teljes / sec	A hálózati interfészen áthaladó bájtok száma másodpercenként. Ha a mérő mutatója csökken, vagy ilyen tendencia van, ez azt jelzi, hogy a hálózati problémák befolyásolhatják az alkalmazást
FIRYILESDISK-LIST Transzferek / SEC	Az olvasási / írási lemez műveleteinek értékelése. Szerelje be a mérőt a kiszolgáló minden fizikai lemezére
Processzor-% processzor idő	Az a százalékos idő, amikor a processzor tölti a munkafolyamat végrehajtását. Ez a számláló elsődleges processzor aktivitási jelzőjeként működik. Ha az SQL Serveren futó processzorok százalékos felhasználást mutatnak, a végfelhasználói kérések legvalószínűbbek
SQLSERVER: Hozzáférési módszerek - teljes vizsgálat / sec	Korlátlan kitöltött táblázatok száma vagy az index szkennelése másodpercenként. A mérő értékeinek csökkentése a jobb, mert a nézetek gyakran a gyorsítótárazási probléma erőforrásainak hiányát okozják
SQLSERVER: pufferkezelő-puffer gyorsítótár hányada	Az olyan oldalak százalékos aránya, amelyek nem igényeltek olvasást a lemezről. Minél magasabb a számuk, annál kisebb a lemez bemeneti / kimenete. Egy jól hangolt rendszerben ez az értéknek 80 vagy annál magasabbnak kell lennie.
SQLSERVER: Adatbázis-napló növekedése	Ami egy adott adatbázis esetében a tranzakciós fájl nőtt. Egy jól hangolt rendszerben a számláló értékének alacsonynak kell lennie, valószínűleg kevesebb, mint egy néhány nap alatt
SQLSERVER: Adatbázisok Alkalmazás adatbázis-százalékos napló	A naplófájlban szabad hely százalékos aránya. Ez a számláló változhat, de nem érheti el a 100-at
SQLSERVER: Adatbázisok Alkalmazás adatbázis-tranzakciók / sec	Az adatbázisban megerősített ügyletek száma. Ez az ellenállási idő csökkenti a szabványokat. Nézze meg, ha a tranzakciók elkezdődnek, ez azt jelzi, hogy a lemez bemenete / kimenet lassú lehet
SQLSERVER: RATCHES-Átlagos retesz várakozási idő	Az átlagos lekérdezési késleltetési idő a kitöltés előtt. Ez az ellenérték maga is lehet, ha a kiszolgáló az erőforrások rivalizálására néz, különösen a memória vagy a bemenet / kimenet esetében
SQLSERVER: Locks-Átlagos várakozási idő, zárolás vár / sec, holtpontok száma / sec	Ideiglenes zárak tartják az SQL Server erőforrásokat. Nézze meg ezeket a csatlakozó blokkolásának felfelé irányuló tendenciáját, ami lehetséges termelékenységi problémát jelez
SQLSERVER: Általános statisztikák-felhasználói kapcsolatok	Az egyéni kapcsolatok száma az adatbázis-kiszolgálóhoz. Ellenőrizze az észrevehető eltolódást a számláló értékében. Jelölhetnek hálózati problémákat, és jelezhetnek terheket és lassulást.
SQLSERVER: A memóriakezelő-memória-támogatások függőben vannak	A memóriahely biztosítására váró folyamatok száma. A magas vagy növekvő érték nem megfelelő memóriát jelezhet.
SQLSERVER: Felhasználó beállítható lekérdezés (Tracer lekérdezés)	Speciális mérő, más néven lekérdezési mutató. Ez a mérő egy felhasználó által létrehozott kérés, amely jelzi a rendszer teljes sebességét vagy hatékonyságát. Az érték beállításához az alkalmazás alkalmazza a SP_USER_COUNTER1-et, és numerikus értéket ad vissza.