Szóval a DAC portját a következőképpen találja ki az SQL Server: ha a default instance-ről van szó, akkor ő alapból a TCP 1434 portra akar ráülni, amennyiben az szabad (ezért lehet praktikus a TCP 1434-et nem odaadni named instance-nak). Ha nem szabad az a port, vagy named instance-ról van szó, akkor választ magának véletlenszerűen egy portot.

Ez persze felvet egy csomó kellemetlen problémát, mindenekelőtt azt, hogy honnan a francból fogom tudni, hogy hol a DAC. Erre a következő megoldások léteznek:

• Elindítod az SQL Browser service-t, ami feltérképezi az adott oprendszeren futó összes SQL instance-ot, és kérdés esetén megmondja. Ez kényelmes, de én rühellem az SQL Browsert, mert szerintem van elég baj anélkül is, hogy egy beépített biztonsági rést használok.
• Felolvasod az SQL Server errorlogjának az első pár tucat sorát, konkrétan a Dedicated admin connection support was established for listening locally on port XXXX. (PowerShell: Select-String “Dedicated admin connection support” [errorlog helye]) Direktben arra a portra kapcsolódsz, mintha csak egy SQL lenne ott (ideális esetben van is).
• Keresel egy szabad portot, amit semmilyen alkalmazás nem bitorol. Ezt te lefoglalod a DAC részére, leírod, kiragasztod az ajtóra, stb. Majd megkéred a DAC-ot, hogy használja is azt a portot. Ezt ugyanis be lehet állítani a registryben, és akkor az SQL Server a 1434 helyett a registryben szereplő értéket fogja defaultnak tekinteni. A kulcs helye pedig a HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\MSSQL.X\MSSQLServer\SuperSocketNetLib\AdminConnection\Tcp gombócban lakó TcpDynamicPorts érték (X= az instance-unk sorszáma). Ami alapból 1434.

Természetesen az egész bejegyzést az egy szem registry kulcsért írtam. Ez egyébként tűzfalas környezetben is nagy segítség lehet, mert jelentősen lehet növelni az esélyét annak, hogy elérjük a SQL-t DAC-on keresztül.

(a megoldás egy MS KB cikkből származik, de sajnos elég kereshetetlen, én célirányos kereséssel nem találtam meg fél óra alatt. Se bing, se gugli.)

Egy clusternél viszont ez nyilvánvalóan nem működhet, ha végiggondoljuk a cluster concepcióját. Az SQL Server csak olyan erőforrásokat használhat, amiken dependál a service (közvetve vagy közvetlenül). Így például maga a SQL Server csak a cluster IP megadott portján tud figyelni, a cluster node-ok saját IP-jén vagy bármi egyében, beleértve a localhostot, nem igazán. Hát így történt. Ha clusterünk van, és akarunk DAC-ot használni, akkor muszáj engedélyeznünk a remote admin connectiont, aminek eredményeképpen a standalone gépen minden IP-n, a clustered instance-nál a cluster IP-n fog figyelni a DAC. Ajánlom mindenkinek, hogy kapcsolja be. Emlékeztetőül a bekapcs:

sp_configure 'remote admin connections', 1;
GO
RECONFIGURE;

Azonnal érvényre jut, lehet ellenőrizni az errorlogban, illetve kapcsolódni DAC-ra előtte-utána.

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.