SQL Server Monitoring Tools: Mit kell nyomon követni és hogyan válasszunk?

Az SQL Server monitorozó eszközök nyomon tudják követni a Windows CPU és lemezaktivitását, a blokkolást, a várakozási statisztikákat, a lekérdezési terveket és az adatbázis elérhetőségét. A megfelelő eszköz tehát attól függ, hogy az SQL Server melyik rétegét kell figyelni, nem pedig a funkciók listájának méretétől.

Ez a útmutató részletezi, hogy mit kell figyelniük az IT csapatoknak, hol ér véget a Windows szerver figyelés és hol kezdődik a SQL-specifikus figyelés, mely beépített Microsoft eszközök állnak rendelkezésre, és hogyan válasszunk megfelelő figyelési megközelítést.

Mi teszi a SQL Server megfigyelést figyelemre méltóvá?

Szerverek figyelése, alapok:

A Microsoft SQL Server szerverinfrastruktúrán fut, így az operációs rendszer teljesítménye számít A magas CPU kihasználtság, memória nyomás vagy lassú tárolás hatással lehet az SQL Serverre, még akkor is, ha a adatbázis motorjával nincs alapvetően probléma.

SQL szerverekhez szükséges adatbázis-specifikus megfigyelés:

Azonban a világos Windows Server metrikák nem feltétlenül jelentenek jó SQL Server teljesítményt. A felhasználók lassú tranzakciókat tapasztalhatnak a blokkolás, a gyenge végrehajtási tervek vagy a lekérdezés várakozások miatt, miközben az alapul szolgáló gép továbbra is egészségesnek tűnik.

Hogyan osztja fel a Microsoft ezt:

A Microsoft ezt a megkülönböztetést saját megfigyelési architektúrájában is tükrözi. A Windows eszközök, mint például a Teljesítménymérő, a rendszer erőforrásait fedik le, míg az SQL Server adatbázis-specifikus lehetőségeket biztosít, beleértve a Lekérdezés-tárolót, Kiterjesztett eseményeket, Tevékenységfigyelőt, hibanaplókat és Transact-SQL megfigyelési képességeket.

Az SQL Server megfigyelésének ezért több kiegészítő réteget kell magában foglalnia, nem csupán egy metrikakészletet.

Milyen adatokat kell nyomon követni az SQL Server monitoring eszközöknek?

A pontos metrikák attól függnek, hogy az IT csapatok elsősorban az infrastruktúra elérhetőségéért, az adatbázis-adminisztrációért vagy az alkalmazás teljesítményéért felelősek. Egy hasznos megfigyelési stratégia széleskörűen kezdődik, és mélyebb SQL Server láthatóságot ad hozzá, ahol a munkaterhelés megköveteli.

1. Szerver és Infrastruktúra Egészség

Kezdje az SQL Server gazda által elérhető erőforrásokkal. A CPU, a fizikai memória, a lemezkapacitás, a lemezolvasási és -írási tevékenység, a hálózati használat és a futó folyamatok biztosítják az infrastruktúra kontextusát az adatbázis teljesítményéhez.

A fontos szempont a korreláció. A magas SQL válaszidők, amelyeket tárolási késleltetés kísér, eltérő vizsgálatot sugallnak a lassú lekérdezésektől, amelyek akkor fordulnak elő, amikor a gazda elegendő CPU-val, memóriával és I/O kapacitással rendelkezik.

A gazda figyelése segít észlelni a problémákat, amelyek több mint az SQL Servert érintik. Egy fizikai vagy virtuális szerver támogató alkalmazásokat, szolgáltatásokat vagy távoli felhasználókat is hosztolhat, akiknek tevékenysége ugyanazokért az erőforrásokért versenyez.

2. SQL Server példány és adatbázis állapot

A következő réteg a adatbázis-motor belsejébe néz.

Fontos területek általában magukban foglalják a várakozásokat, aktív munkameneteket, blokkolásokat, holtpontokat, az adatbázis fájl növekedését, a tranzakciós napló használatát és a TempDB tevékenységet. Az adminisztrátoroknak figyelemmel kell kísérniük az adatbázis állapotát, a kapcsolatokat, a memória viselkedését és az SQL Server szolgáltatásokat.

A várakozási statisztikák különösen hasznosak, mert segítenek azonosítani, hogy milyen SQL Server feladatokra várakoznak, ahelyett, hogy csak azt mutatnák, hogy a rendszer lassú. A blokkolások és holtpontok további láthatóságot biztosítanak, segítve azonosítani, hogy a konkrét tranzakciók versenyeznek-e az erőforrásokért.

A dedikált adatbázis-figyelő platformok következésképpen sokkal mélyebbre hatolnak, mint a hosztfigyelők. Például az IDERA SQL Diagnostic Manager dokumentálja a várakozások, blokkolási láncok, holtpontok, TempDB nyomás, I/O késleltetés és az adatbázis növekedésének figyelését.

3. Lekérdezés és Terhelés Teljesítmény

Miután egy problémát a adatbázis terheléshez lokalizáltak, az összesített szerver metrikák gyakran elégtelenek. Az adminisztrátoroknak meg kell határozniuk, hogy mely lekérdezések fogyasztanak túlzott erőforrásokat, és hogy a viselkedésük megváltozott-e.

A hasznos lekérdezés szintű információk közé tartozhat a végrehajtási időtartam, a CPU-fogyasztás, a logikai és fizikai olvasások, a memóriafogyasztás, a végrehajtási gyakoriság, a várakozások és a végrehajtási tervek.

Microsoft Query Store jó példa arra a szoftverre, amely erre készült. Megőrzi a lekérdezéseket, terveket és futási statisztikákat, így a rendszergazdák időben megvizsgálhatják a teljesítményt, és azonosíthatják a lekérdezés-terv változásaival kapcsolatos regressziókat. Az SQL Server 2017 és újabb verziók képesek várakozási statisztikák rögzítésére a Query Store segítségével.

Ez a történelmi kontextus fontos, mert sok SQL Server probléma időszakos. Hasznos tudni, hogy a CPU tegnap délután 90%-ra emelkedett. Azt is hasznos tudni, hogy mely lekérdezések viselkedése változott meg ugyanabban a pillanatban, mivel ez potenciális beavatkozási lehetőségeket azonosít.

4. Elérhetőség, Munkahelyek és Működési Egészség

A teljesítmény csak egy szempont az SQL Server figyelésében. A működési hibák befolyásolhatják a rendelkezésre állást és a helyreállíthatóságot, még akkor is, ha a munkaterhelés teljesítménye normálisnak tűnik.

A környezettől függően az adminisztrátoroknak szükségük lehet a SQL Server Agent feladatok, biztonsági mentések, adatbázis elérhetőség és az Always On Availability Groups láthatóságára. A nagyobb vagy üzletileg kritikus ingatlanok esetében a replikációs monitorozás, a konfigurációs nyomon követés és a kapacitás-előrejelzések is szükségesek lehetnek.

A szükséges mélységnek követnie kell a munkaterhelés fontosságát. Egy kis belső adatbázis vagy egy klaszterezett termelési SQL Server környezet nagyon különböző megfigyelési architektúrákat igényel.

Milyen beépített SQL Server figyelőeszközöket használhat?

Mielőtt dedikált platformot vásárolna, érdemes megérteni, hogy mi Microsoft SQL Server már biztosítja.

Széleskörű natív eszközök:

• Az Activity Monitor támogatja az ad hoc ellenőrzést
• A Lekérdezés Tároló megőrzi a történelmi lekérdezési és tervinformációkat.
• Kiterjesztett események rögzítik a kiválasztott motor eseményeket
• A Dinamikus Menedzsment Nézetek feltárják a belső teljesítményadatokat
• Az SQL Server hibanaplók segítenek a adatbázismotor eseményeinek kivizsgálásában.
• A Windows Performance Monitor operációs rendszer erőforrás-információkat ad hozzá.

Mélyebb diagnosztika, de nagyobb összetettség:

Ezek az eszközök jelentős diagnosztikai mélységet nyújthatnak, különösen tapasztalt adatbázis-adminisztrátorok számára. Emellett elkerülik egy másik bevezetését. megfigyelő platform amikor az alkalmi hibaelhárítás elegendő.

Gyakran nem az adatokhoz való hozzáférés a korlátozásuk, hanem a működési kényelem. Egy IT csapat, amely több szervert kezel, központosított irányítópultokat, tartós történeteket, egyszerűbb figyelmeztetéseket és gyorsabb korrelációt szeretne, ahelyett, hogy információkat gyűjtene össze több SQL Server és Windows felületről.

Itt válik vonzóbbá a harmadik fél általi megfigyelés.

Hogyan válasszunk SQL Server megfigyelő eszközöket?

Kezdje a problémával, amelyet az eszköz megoldani hivatott. Ez megakadályozza, hogy elveszítse a célját a támogatott mutatók legnagyobb számának ellenőrzőlistájában.

1. Szükséges láthatósági mélység

Hasznos első kérdés, hogy szüksége van-e infrastruktúra-figyelésre, adatbázis-motor diagnosztikára vagy részletes lekérdezés-elemzésre.

Követelmény	Megfigyelési megközelítés
CPU, memória, lemez és szerver elérhetőség	Szerver- vagy infrastruktúrafigyelés
Időszakos SQL Server hibaelhárítás	Beépített Microsoft SQL Server eszközök
Blokkolás, várakozások, holtpontok és adatbázis figyelmeztetések	Dedikált SQL Server megfigyelés
Lekérdezési tervek és teljesítmény-visszaesések	Lekérdezés tároló vagy fejlett SQL megfigyelés
Nagy többpéldányos SQL ingatlan	Központosított adatbázis-figyelés
SQL Server plus szélesebb alkalmazásfüggőségek	Infrastruktúra vagy teljes stack megfigyelés SQL-specifikus monitorozással kombinálva

Ezek a kategóriák átfedhetik egymást. Sok környezetben a legpraktikusabb megközelítés a kombináció, nem pedig egyetlen termék.

2. A figyelmeztetések és a történelem összehangolása a műveletekkel

A megfigyelés akkor válik a leghasznosabbá, amikor kiemeli a rendellenes viselkedést, mielőtt a felhasználók problémát jelentenének.

Nézze meg, hogy egy eszköz támogatja-e a küszöbérték-figyelmeztetéseket, a történelmi trendeket és elegendő kontextust az esemény utólagos kivizsgálásához. A szakosodott SQL platformok tovább léphetnek azzal, hogy blokkolási láncokat, holtponti grafikonokat vagy lekérdezési információkat csatolnak közvetlenül a figyelmeztetéshez. A Redgate Monitor például SQL-specifikus figyelmeztetéseket dokumentál olyan eseményekről, mint a holtpontok, a sikertelen feladatok, a blokkolt lekérdezések és a hosszú ideig futó lekérdezések.

A kiindulási alapok beállítása szintén fontos. Egy érték, amely egy adatbázis számára rendellenes, lehet, hogy egy másik számára rutin, ezért az értesítéseknek tükrözniük kell az egyes munkaterhelések viselkedését és üzleti fontosságát.

3. Fontolja meg a méretet, a telepítést és az adminisztrációt

Egy eszköz, amely alkalmas egy SQL Server példányra, zavaróvá válhat több tucat szerver esetén.

Fontolja meg, hány gazdagép, példány és adatbázis igényel figyelmet, hogyan gyűjtik és tárolják a figyelési adatokat, valamint mennyire könnyen tudják az adminisztrátorok összehasonlítani a rendszereket egy központi konzolról. A licencelést, a telepítési erőfeszítést, a jelentéskészítést és az értesítések kezelését ezért a technikai mélységgel együtt kell értékelni.

A cél nem az, hogy minden lehetséges mérőszámot összegyűjtsünk. Az, hogy a legrelevánsabb információkat elegendő mennyiségben gyűjtsük össze az abnormális viselkedés azonosításához, és lerövidítsük az utat a tünettől az okig, hogy az IT technikusai meg tudják oldani a problémát.

Hol illeszkedik a TSplus Server Monitoring?

A TSplus Server Monitoring a megfigyelési modell infrastruktúra oldalát célozza meg. Biztosítja valós idejű láthatóság a CPU, memória, lemez olvasási és írási tevékenység, sávszélesség, folyamatok és csatlakoztatott felhasználók, együtt a történeti jelentésekkel és a konfigurálható riasztásokkal a szerver metrikákhoz.

A Microsoft SQL Server-t futtató Windows szerver esetében ez a láthatóság segít meghatározni, hogy egy adatbázis teljesítményproblémája egybeesik-e a CPU terhelésével, a memóriafogyasztással, a lemezaktivitással vagy egyéb, a gazdagép szintjén fellépő állapottal. A történeti jelentések szintén kontextust nyújtanak a visszatérő infrastruktúra problémákhoz.

A TSplus Server Monitoring azonban nem egy dedikált SQL Server adatbázis teljesítmény-elemző. Az SQL-specifikus követelmények, mint például a végrehajtási terv elemzése, a Query Store vizsgálata, a blokkolási láncok, a holtpont-elemzés vagy a részletes várakozási statisztikák a Microsoft SQL Server eszközeit vagy egy szakértői adatbázis-figyelő terméket igényelnek.

Sok IT csapat számára ezek a rétegek kiegészítik egymást. TSplus Szerver Figyelés egyszerű áttekintést nyújthat a szerver állapotáról és az erőforrás-felhasználásról, míg az SQL Server natív eszközei mélyebb adatbázis-átláthatóságot biztosítanak, és segítenek azonosítani, amikor egy esemény az adatbázis-motorra vagy egy adott munkaterhelésre mutat.

Következtetés

Az SQL Server megfigyelő eszközök közötti választás azzal kezdődik, hogy eldöntjük, mi igényel láthatóságot. A szerver erőforrásai, az adatbázis-motor állapota és a lekérdezés teljesítménye a rendszer különböző rétegeit képviselik, és egyetlen mutató sem magyarázza meg mindet.

Kezdje az infrastruktúra állapotával, majd adjon hozzá SQL-specifikus megfigyelést, ahol a munkaterhelés mélyebb diagnózist igényel. Ez a réteges megközelítés gyakorlati szempontból tartja a megfigyelést, miközben elegendő kontextust biztosít az IT csapatok számára, hogy megkülönböztessék a szerverproblémát az adatbázis- vagy lekérdezési problémától.

Néhány Gyakran Ismételt Kérdés

Mi az SQL Server megfigyelő eszköz?

Egy SQL Server megfigyelő eszköz nyomon követi a Microsoft SQL Server környezetek egészségét, teljesítményét vagy elérhetőségét. Hatókörétől függően figyelheti a gazda erőforrásait, adatbázisokat, várakozásokat, blokkolásokat, lekérdezéseket, feladatokat, biztonsági másolatokat vagy elérhetőségi konfigurációkat.

Milyen SQL Server metrikákat kell figyelnem?

A fő mutatók, amelyek a terheléstől függenek, általában tartalmazzák a CPU-t, a memóriát és a tárolást. Ezen kívül az SQL-specifikus jelzők jelzik a várakozásokat, a blokkolást, a holtpontokat, az adatbázis növekedését, a tranzakciós naplókat, a TempDB aktivitást, a lekérdezések időtartamát és a feladat állapotát.

A Windows Server monitoring képes észlelni az SQL Server problémákat?

A Windows Server monitoring képes azonosítani az SQL Server-t érintő infrastruktúra problémákat, beleértve a CPU, memória és lemeznyomást. Önmagában nem tudja megmagyarázni az adatbázismotorral kapcsolatos problémákat, mint például a lekérdezési terv regressziók, blokkolási láncok vagy SQL-specifikus várakozások.

Tartalmaz-e az SQL Server saját monitoring eszközöket?

Igen. A Microsoft SQL Server olyan eszközöket és lehetőségeket tartalmaz, mint a Query Store, az Extended Events, az Activity Monitor, a Dynamic Management Views, a hibanaplók és a Transact-SQL teljesítményfunkciók. Alkalmazhatóságuk az eseménytől vagy a vizsgált terheléstől függ.

Szükségem van dedikált SQL Server megfigyelő szoftverre?

Nem feltétlenül. A beépített eszközök elegendőek lehetnek kis környezetekhez vagy alkalmi hibaelhárításhoz. Kombinálva TSplus Szerver Figyelés Általános célokra a Microsoft SQL Server beépített monitora alig irigyelheti a harmadik féltől származó monitorozó termékeket. A dedikált monitorozás akkor válik hasznosabbá, amikor a csapatok központosított láthatóságra, folyamatos figyelmeztetésekre, hosszú távú történetre vagy gyorsabb diagnózisra van szükségük több SQL Server példány között.