SQL teljesítményelemzés morzsák

Az egyik visszatérő kérdés: mit nézzek, ha baj van? Erre több megközelítés is lehetséges: lehet az Indexet, majd elmúlik a baj; esetleg olvasgatni dokumentációt vagy guglizni; vagy álláskereső portált nézni; netán a szerver teljesítményét megvizsgálni.

Ja, de hogyan? Hát, elmondom, hogy én kb. miket csinálok, amikor döglődik az SQL. Ez részben szisztematikus, részben nem, ugyanis vannak dolgok, amiket lehet párhuzamosan csinálni, vagy felcserélhetőek, vagy esetleg egyik a másikat feleslegessé teszi, vagy valami tök más is beugorhat, ha valami tök mást látok. De mondjuk, hogy az esetek 85%-ában az általam üzemeltetett szerverek 90%-a ilyenekkel kezelhető. Ezek kis ötletgombócok, nem egy script, amit le kell futtatni.

Először is: ne csak performance countert nézzünk, hanem minden mást is. Tipikusan DMV-ket és perfocuntert. Az activity monitort csak indikátornak ajánlom: ha működik, akkor nem lehet nagy baj. Valahogy igen erőforrásigényes szegényke, és amikor jön a terhelés, rendszeresen aszongya, h timeout. Én a következő útvonalon haladok:

Kezdetnek írjuk fel egy papírra, és tegyük a monitor mellé: Memória, CPU, Diszk I/O. Ez a három dolog kell a SQL-nak. Egyszerű rendszer, egyszerű lelkeknek.
Continue reading ‘SQL teljesítményelemzés morzsák’ »

SQL Server Standard Edition és Lock Pages in memory 64 biten

Ha az ember egy erősebb vason SQL Server Standard Editiont futtat, akkor találkozhat a kedves hibaüzenettel az errorlogban:
A significant part of sql server process memory has been paged out. This may result in performance degradation
Ez kellemetlen lehet, a oprendszer kitalálja, hogy neki másra (is) kell memória, és kiülteti az SQL-t a kispadra, aminek a teljesítménye tényleg leromolhat ilyenkor, nem viccel az errorlog.

Enterprise Edition esetén ez nem probléma, mivel az rendelkezik a mágikus “Lock pages in memory” képességgel (feltéve, hogy a futtató user megkapta a szükséges OS-szintű jogot), de a standardon bizony sokat szívtak ezzel emberek, beleértve engemet is. Éppen ezért örülök nagyon annak, hogy végre kivették ezt a bosszantó korlátozást, pontosabban kiveszik hamarosan. Még pontosabban egy trace flag segítségével be lehet majd kapcsolni azt, hogy lehessen lockolni a memóriába a lapokat. A várható szállítási idők:

  • SQL 2008 SP1 CU 2 – 2009 május
  • SQL 2005 SP3 CU 4 – 2009 június

Én már felírtam a naptáramba :) A PSS blogon az eredeti post itt olvasható.

A három legfontosabb dolog az életben

A fenti kérdésre a válasz mindenkinél változó, de az SQL Server egyszerű lélek:

  • master adatbázis data file
  • master adatbázis log file
  • errorlog

Ha ezt a három fájlt meg tudja nyitni, már boldog. És ha nem? Mindig az errorloggal kezdjük vizsgálódásainkat. Ha nem találjuk az errorlogot, nézzük meg, hogy van-e joga oda írni a SQL-t futtató accountnak. Ha megtaláljuk az errorlogot, akkor meg olvassuk el.
A fenti paraméterek egyébként az SQL Server Configuration Managerben láthatóak és állíthatóak (meg a registryben).

Gyorsan jogot az összes tárolt eljárásra

Éppen építem a félautomata SQL Servert (mint már párszor említettem), és ennek egyik állomása az, hogy a szakmailag kevéssé felkészült, ámde elszánt fejlesztők ellen, akik hibernate-ben mindent összedobálnak, elveszem az alkalmazások dbo jogát, és helyette csak írni-olvasni tudnak majd. Ez jó ötlet, hiszen ott van a beépített db_datareader és db_datawriter role minden adatbázisban, de…

A problémát a tárolt eljárások és függvények okozzák, amelyekhez külön-külön kell jogot grantolni. Ezt persze lehet scriptből is, de azért elég jó esély van arra, hogy ezt el fogom izélni valamikor, és nem lesz joga az alkalmazás usernek vmit csinálni, mire azt mondják, hogy azonnal adjam vissza a dbo jogot. Ennek a problémának a kivédésén agyaltam, és már-már kezdtem hajlani a DDL triggerek felé (minden SP gyártás után automatikusan adjuk rá jogot a megfelelő usernek), amikor egy számomra sokkal szimpatikusabb ötletbe botlottam.
Continue reading ‘Gyorsan jogot az összes tárolt eljárásra’ »

Az légy, aki lenni akarsz

A cím nem a személyiségfejlődéshez, inkább a más accountok megszemélyesítéséhez kapcsolódik. Az SQL Server ugyanis lehetőséget ad arra, hogy egy megfelelő jogosultságokkal rendelkező login alól egy másik loginra (vagy userre) váltsunk át, és annak a nevében futtassunk lekérdezéseket. Ez különösen hasznos lehet például hibakeresésnél vagy ha vissza akarunk élni a hatalmunkkal.

SQL 2000 alatt már megvolt a SETUSER nevű parancs, ami átváltott egy megadott user alá, és viszonylag lehetett használni, de az igazi boldog élet a 2005-tel köszöntött be, ő hozta el az EXECUTE AS utasítást. Itt már megmondhatjuk, hogy database user vagy server login szinten akarunk imperszonálni, lehet ezt a privilégiumot bárkinek megadni (SETUSER csak sysadmin vagy dbo joggal megy), illetve lehet több szint mélyre lemászni, és onnan visszajönni.
Continue reading ‘Az légy, aki lenni akarsz’ »