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.

• Oprendszer CPU és memória. Ha ki van ültetve a CPU vagy nincs szabad memória, akkor már világos, hogy a fizikai erőforrás fogyott el. Megosztott gépen kérdés, h mennyi jutott a SQL-nek.
• Ha véletlenül működik az activity monitor, akkor a recent expensive queries gombócot érdemes megnézni, a végrehajtások számával együtt!
• Megnézem, h hova lett az az erőforrás, amiből kifutottunk. Extrém esetekben lehet, h van szabad fizikai erőforrás, ebben az esetben a háromság harmadik lábát, a diszk I/O-t is érdemes megnézni. Azaz perfcounter, Physical disk – Avg Disk (Read/Write) queue Length. Emellett hasznos lehet a % Disk Read/Write time is, DE vegyük be a counterek közé a % Idle time-ot is, mert a % Disk Read/Write time hajlamos többet hazudni, mint a tényleges (azaz az idle a megbízható a történetben).
• A háromból az egyik tuti nem jó. Megnézem hogy ki gyilkolja azt. Ezt különféle DMV-kből lehet kiszippantani, kezdjük barátunkkal, a sys.dm_exec_sessions nevűvel. A memory_usage oszlop adja magát, ez 8KB-os lapokban mondja meg a használatot, és vele a legegyszerűbb dolgozni. A cpu_usage, a reads és writes meg azért nehezebb, mert ott bizony változást kell számolni, mivel az aktuális érték semmitmondó magában. Kétmillió olvasás két hét alatt azért nem olyan sok például. Ezt persze a sysprocessesből is ki lehet venni, majdnem ugyanaz, nekem még erre van egy scriptem:

  if object_id('tempdb..##c1') is not null
  begin
  drop table ##c1 drop table ##c2
  end
  select session_id, login_time, sum(cpu_time) cpu, sum(reads) reads, sum(writes) writes into ##c1 from sys.dm_exec_sessions group by session_id, login_time
  waitfor delay '000:00:10'
  select session_id, login_time, sum(cpu_time) cpu, sum(reads) reads, sum(writes) writes  into ##c2 from sys.dm_exec_sessions s group by session_id, login_time
  select c2.cpu-c1.cpu cpudiff, c2.reads-c1.reads [read], c2.writes-c1.writes write, p.memory_usage/128 mem_used_MB, p.login_name, p.cpu_time, p.*
  from sys.dm_exec_sessions p
  join ##c1 c1
  on p.session_id= c1.session_id
  join ##c2 c2
  on p.session_id= c2.session_id
  where
  c2.cpu > c1.cpu
  or c2.writes > c1.writes
  or c2.reads > c1.reads
  or p.memory_usage > 15*128 -- 15 MB
  order by c2.cpu-c1.cpu desc
  -- majd tessék dropni a temptáblát. Azért nincs itt a végén, hátha bogarászni akarunk még bennük
  

• Ekkorra már nagyjából illene, hogy legyen sejtésünk a drágaság forrásáról, legalább olyasmi, h melyik alkalmazás. Jöhet a DBCC INPUTBUFFER() vagy nekieshetünk profilerrel is, ízlés dolga. Aztán egyszer eljutunk egy objektumhoz. Ha tempdb, akkor valaki valami beteg joinokat csinál általában, nézzünk ilyen szemmel a futtatott kverire. Ha pedig vmi user tábla, akkor vagy full table scan futkos rajta sokat, vagy kéne venni memóriát.
• Személyes tapasztalatom az, hogy az esetek 30%-ában valaki kiülteti a procit, azt a fenti script lokalizálja, aztán a kill paranccsal orvoslom. 70% az erős memóriahiányos állapot, ekkor meg a BOL-ból kiveszek két scriptet, a sys.dm_os_buffer_descriptors oldaláról: az első (azaz A.) megmondja, hogy mennyi memóriát esznek az adatbázisaim:

  		SELECT count(*)AS cached_pages_count
      ,CASE database_id
          WHEN 32767 THEN 'ResourceDb'
          ELSE db_name(database_id)
          END AS Database_name
  FROM sys.dm_os_buffer_descriptors
  GROUP BY db_name(database_id) ,database_id
  ORDER BY cached_pages_count DESC;
  

  Itt nézzük meg, hogy az összeg meg a használt memória stimmelnek-e nagyjából. Pl. elszúrt alkalmazás tele tudja hányni a procedure cache-t, ami meghízik szép csendben két gigára, aztán néz az ember, mert az adatbázis lapoknak nem maradt hely. A B kveri meg ugyanezt tudja, adatbázis szinten. Itt is jól látszik, h ki lakik a memóriában, még az is, h melyik index (vagy a tábla maga). Ilyenkor lehet kiválóan procedure cache-t üríteni (DBCC CLEANPROCCACHE – ez az egész szerverre lefut, szóval odavághat kicsit a teljesítménynek, mert mindent újra kell fordítani, de itt talán már mindegy).

Majd valaki rúgjon oldalba, ha még idén nem írok a latchekről is valamit.

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ó.

• 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).

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.

Hozzunk létre egy új role-t, és az új role-nak grantoljunk execute jogot a dbo schema-n (ha van más séma használatban, akkor azon is). Ez azt jelenti, hogy egy háromsoros scriptet kell lefuttatnom a model adatbázison, az adatbázis generáló scriptemhez pedig egy sort kell hozzáadnom, és már kész is vagyok. A háromsoros script a modelhez:

CREATE ROLE db_spexecution AUTHORIZATION dbo
GO
GRANT EXECUTE ON SCHEMA::[dbo] TO db_spexecution

A plusz egy sor az adatbázis gyártáshoz:

sp_addrolemember 'db_spexecution', 'dbusername'

Mivel a függvényekhez is execute jog kell, megoldottam a kívánságaimat. Remélem. Teszt következik… :)

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.

Az EXECUTE AS parancs kiváló huncutkodásokra ad lehetőséget, de persze azért van mód megtudni, hogy ki vagyok én valójában:

-- nézzük meg, hogy ki vagyunk
SELECT SUSER_NAME() [login], USER_NAME() [user]
-- legyünk sa
EXECUTE AS LOGIN = 'sa'
GO
SELECT SUSER_NAME() [login], USER_NAME() [user]
-- de honnan tudom, hogy ki voltam?
SELECT ORIGINAL_LOGIN()
-- menjünk vissza
REVERT

Hát ennyi. Illetve… van itt még valami: definiálhatunk UDF-et, SP-t sőt triggert is EXECUTE AS clause-zal, ami meghatározza, hogy kinek a nevében fog lefutni a lefutnivaló. Az alábbi SP-t egy user adatbázisban hoztam létre, ahol a mytestdbuser nevű SQL loginhoz mappelt azonos nevű db user lakik, mindenféle jog nélkül:

CREATE PROCEDURE uspKivagyok
WITH EXECUTE AS 'mytestdbuser'
AS
BEGIN
SELECT SUSER_NAME(), ORIGINAL_LOGIN()
END

Ez nagyon jó, de mi a haszna? Még finomabban tudom hangolni a jogosultságokat, ott is, ahol egyébként nem tudnám. Pl. nem lehet a TRUNCATE TABLE jogot delegálni – ha egy SP-be csomagolom, az SP-re annak adok jogot, akinek akarok, az SP pedig fut egy dbo nevében.