Dedicated Admin Connection röviden

SQL 2005-öt (vagy 2008-at) használsz? Olvastad az új fícsörök listáját? Akkor tudod, hogy van egy úgynevezett Dedicated Administrator Connection, barátok közt DAC, mely kiskapu egy üzemeltetőnek kínál hátsó bejáratot arra az esetre, ha valami rettenetes dolog történik, és egyébként már nem lehet belogolni se az SQL-be. Tipikus esetek lehetnek: valami durván kihajtja/széjjellockolja az SQL szervert vagy valaki elizélt logon triggereket alkalmaz, melyek nem tudnak lefutni, és így senki nem tud belogolni, még azért sem, hogy kikapcsolja a logon triggereket. Érezhető, hogy a klasszikus “újraindítom, az segíteni szokott” szemlélet az első két esetben segíthet (de soha nem tudod meg, hogy ki vágta haza a szervert és mivel), de az utóbbi esetben csak elodázza az elkerülhetetlent.

DAC-hoz való kapcsolódás alapból csak lokálisan engedélyezett, ez azért jó, mert ha kell a DAC, akkor nem kell azon agyalnod, hogy vajon ki használja az egy darab kapcsolatodat, csak valaki lokálisan lehet, azt meg könnyű kirúgni. Hogyan is működik a DAC? Az SQL Server indulásakor ő is elkezd figyelni egy porton, amit ő véletlenszerűen talál ki (sejtsük, hogy ez tűzfal mögül nem feltétlenül fog jól működni). Amikor hozzá akarunk csatlakozni, akkor a szerver neve elé be kell írnunk az admin: prefixet, azaz a SQL1 szerver DAC kapcsolatához az admin:SQL1 nevet kell megadnunk.

A DAC default instance esetén szeret a 1434-es TCP porton figyelni, ha teheti. Ha nem, akkor mást választ, tehát amikor kapcsolódunk, ezt valahonnan meg kell tudnunk. Az SQL Browser hivatott arra, hogy megadja ezt az információt, de ha valamilyen oknál fogva ez nem jön össze, vagy csak szereted letiltani a browsert, akkor sincs minden veszve:

sqlcmd -Stcp:SQL1,3247

Ahol a 3247-es portot kiolvastuk az SQL errorlogjából (indulás környékén lehet megtalálni, a példában a 6-7. sor):

...
2009-04-05 13:03:20.03 Server      Server is listening on [ 'any' <ipv4> 1433].
2009-04-05 13:03:20.03 Server      Server local connection provider is ready to accept connection on [ \\.\pipe\SQLLocal\MSSQLSERVER ].
2009-04-05 13:03:20.03 Server      Server local connection provider is ready to accept connection on [ \\.\pipe\sql\query ].
2009-04-05 13:03:20.04 spid9s      Starting up database 'model'.
2009-04-05 13:03:20.04 Server      Server is listening on [ 127.0.0.1 </ipv4><ipv4> 3247].
2009-04-05 13:03:20.04 Server      Dedicated admin connection support was established for listening locally on port 3247.
...

A fenti példából láthatjuk, hogy a DAC a 127.0.0.1-en, azaz a localhoston figyel, tehát nem elérhető máshonnan, csak belogolva az SQL Servert futtató host oprendszerbe.

Ha esetleg kényszert éreznénk arra, hogy engedélyezzük a DAC-hoz való kapcsolódást távolról is, akkor azt az sp_configure tárolt eljárással tehetjük meg:

-- ez már advanced opció, előbb azt be kell kapcsolnunk
sp_configure 'show advanced options', '1';
RECONFIGURE;
GO
-- olvassuk ki a pillanatnyi értéket, ez gyárilag nulla
sp_configure 'remote admin connections'
-- és most kapcsoljuk be
GO
sp_configure 'remote admin connections', 1;
GO
RECONFIGURE;
GO

És már mehetünk is neki távolról azon nyomban. A fenti tevékenység az alábbi bejegyzéseket generálja az errorlogban:

...
2009-04-05 15:30:23.29 spid76      Configuration option 'show advanced options' changed from 0 to 1. Run the RECONFIGURE statement to install.
2009-04-05 15:30:23.62 spid76      Configuration option 'remote admin connections' changed from 0 to 1. Run the RECONFIGURE statement to install.
2009-04-05 15:30:23.65 Server      Server is listening on [ 'any' </ipv4><ipv4> 3247].
2009-04-05 15:30:23.65 Server      Dedicated admin connection support was established for listening remotely on port 3247.
...

Láthatjuk, hogy a localhost helyett minden lehetséges IP-n figyel a DAC mostantól fogva.

Tartsuk észben: egyetlen darab DAC kapcsolat engedélyezett, tehát vagy egy database engine query vagy egy sqlcmd fog összejönni, az object browsert felejtsük el. Ezért praktikus alapbeállítás az, hogy nem lehet használni távolról. Ne legyen probléma, hogy esetleg valaki belépett, úgy maradt, és amikor nagy a baj, még meg is kell keresni, hogy ki az, és honnan. Hogyan keressük meg, hogy ki az, ha már kapcsolódni sem tudunk? Hát, felnyitjuk az errorlogot, megkeressük benne a fenti logdarabka utolsó bejegyzését, ebből látjuk a portot, aztán utána netstat -n |find “3247”, ebből látni fogjuk a kapcsolat túlsó végét, valami ilyesmit:

TCP    192.168.1.101:3247     192.168.1.25:1843       ESTABLISHED 

és a 192.168.1.25 gépen egy netstat -no | find “1843” paranccsal megnézhetjük, hogy melyik processz fogja az adott portot (Linuxos kliens esetén netstat -np|grep 1843), és kis szerencsével van jogunk legyilkolni, így felszabadíthatjuk a DAC-ot, és végre kapcsolódhatunk. Ez érezhetően kissé körülményes, ezért jobb nem kerülni ilyen helyzetbe.

A DAC-nak vannak bizonyos korlátai, ugyanis alapvetően gyors hibaelhárításra és diagnosztikára tervezték, véges erőforrás áll rendelkezésünkre, és csak egy szálon dolgozhatunk (egy több szálon futó utasítás, mint pl. RESTORE, elhal). A tipikus tevékenység a különféle DMV-k lekérdezgetése és a kill parancs szisztematikus használata, illetve elcs vicces logon triggerek letiltása/törlése.

Összességében azért érdemes gondolni rá, DE: egy jótanács: rakjátok össze előre a diagnosztikai lekérdezéseiteket (és tegyétek jól elérhető helyre, akár bele a master adatbázisba is custom SP képében), mert akkor és ott ezzel bénázni nyakatokban a hörgő ügyféllel/üzlettel/akárkivel az álmoskönyv szerint lúzerséget jelent.

Hazudtam. Nem volt annyira rövid.

Leave a comment