Databaserecovery. Heb jij al getest?
Tapes Iedereen kent het wel, het wisselen van tapes en deze afvoeren naar een veilige, off-site, omgeving of in een…
Wanneer je een nooduitgang nodig hebt
De echte waarde van de DAC ontdek je vaak pas op het moment dat je hem echt nodig hebt. Dit merkte ik jaren geleden tijdens een incident bij een klant. Hun VMware-cluster kampte met een tekort aan fysiek geheugen – er was simpelweg niet genoeg werkgeheugen beschikbaar voor alle gevirtualiseerde servers die erop draaiden. Dit fenomeen staat bekend als ‘ballooning’. VMware reageerde hierop door agressief geheugen terug te vorderen van één van de servers waarop SQL Server draaide. Het gevolg was heftig: de SQL Server werd volledig onbereikbaar voor bijna een kwartier. Pas toen de zogenaamde ‘noisy neighbour’ – een andere server die veel resources verbruikte – klaar was met zijn zware taak, kwam de communicatie weer op gang. SQL Server zelf was gelukkig wel blijven draaien en wist snel weer wat geheugen te pakken om zijn taken uit te voeren. Helaas had MS DTC (Microsoft Distributed Transaction Coordinator) het wel voor gezien gehouden en moest opnieuw worden opgestart.
De eerste kennismaking met DAC
Na dit incident heeft de provider van de VMware-host direct actie ondernomen en extra geheugen geïnstalleerd. Hierdoor heeft de klant gelukkig nooit meer last gehad van vergelijkbare problemen. Tijdens de evaluatie die volgde, kreeg ik de kans om dieper in de materie te duiken. Het was tijdens dit onderzoek dat ik voor het eerst stuitte op het bestaan van de DAC. Hoewel ik deze functionaliteit op dat moment nog niet kende – en hem dus ook niet had kunnen inzetten tijdens het incident – bleef het concept wel in mijn achterhoofd hangen. Achteraf gezien had deze tool precies kunnen zijn wat we nodig hadden tijdens die kritieke vijftien minuten van onbereikbaarheid.
Zo werkt de Dedicated Admin Connection
De DAC is een bijzondere functie binnen SQL Server. Deze functionaliteit zorgt ervoor dat het systeem altijd één thread exclusief vrijhoudt voor noodgevallen. Dit betekent dat je zelfs wanneer alle andere processen vastlopen door gebrek aan resources, toch nog bepaalde acties kunt uitvoeren op je database. Er zijn wel wat beperkingen: je kunt bijvoorbeeld niet werken via de Management Studio Object Explorer, maar alleen via een query-window. Ook parallelle queries zijn niet mogelijk. Maar het mooie is dat je wel precies kunt doen wat je in zo’n noodsituatie nodig hebt – zoals het opsporen en stoppen van die ene zware query die al je resources opeet.
Toegang krijgen tot je DAC
Om de DAC te gebruiken, prefix je de servernaam met ‘ADMIN:’. Bijvoorbeeld: ADMIN:dbsrv1. Alleen mensen met sysadmin-rechten krijgen toegang, en er mag maar één DAC-verbinding tegelijk actief zijn. Met deze query check je wie de connectie bezet houdt:
SELECT s.host_name, s.original_login_name, s.session_id, s.login_time, s.status
FROM sys.endpoints e
JOIN sys.dm_exec_sessions s ON s.endpoint_id = e.endpoint_id
WHERE e.name = ‘Dedicated Admin Connection’
Remote toegang: de afweging tussen veiligheid en bereikbaarheid
Standaard werkt de DAC alleen vanaf de server zelf. Voor remote toegang moet je de ‘remote admin connections’ parameter activeren:
sp_configure ‘remote admin connections’, 1;
RECONFIGURE
Leren van ervaring
In het geval van dat eerdere incident had ik helaas weinig aan de DAC, omdat de ‘remote admin connections’-parameter was uitgeschakeld. Hierdoor kon ik niet op afstand inloggen op de server. Had ik wel remote toegang gehad, dan had ik direct kunnen kijken naar de ’total server memory’ in sys.dm_os_performance_counters om het probleem te analyseren. Maar ja, dat is wijsheid achteraf.
Addertje onder het gras
Dit brengt meteen een interessant dilemma aan het licht. Je zou kunnen zeggen: “Zet die ‘remote admin connections’-parameter gewoon standaard aan – je weet immers nooit wanneer je hem nodig hebt.” Maar hier zit een addertje onder het gras. De CIS Benchmark voor SQL Server raadt dit namelijk af. Hun redenering? Het vergroot je ‘attack surface area’ – het gebied waarop aanvallers mogelijk kunnen toeslaan. En natuurlijk wil je dat gebied juist zo klein mogelijk houden.
Aan of uit?
Het is een klassiek dilemma in database beheer. Aan de ene kant wil je voorbereid zijn op noodgevallen en snel kunnen ingrijpen. Aan de andere kant wil je je systeem zo goed mogelijk beschermen. Beide keuzes – de parameter aan of uit – maken in de praktijk meestal niet veel uit. Maar zoals we in de IT weten: het zijn vaak de uitzonderlijke situaties die het verschil maken.
Hoe ga jij om met de DAC?
Elke database-omgeving is anders. Misschien heb je altijd fysieke toegang tot je servers en houd je remote connections uitgeschakeld. Of je accepteert het security-risico omdat snelle toegang bij problemen cruciaal is. Of je schakelt remote access pas in na het eerste incident.
Deel je ervaring
Vanwege de veiligheidsrisico’s zijn wij er voorstander van om de ‘remote admin connections’-parameter uit te laten staan. Maar wellicht heb jij ervaring met het gebruik van DAC in kritieke situaties vanuit een andere server? Deel deze pagina op LinkedIn en laat ons weten wat jouw ervaringen zijn – zo help je andere databaseprofessionals slimme keuzes maken voor hun omgeving.
Meer weten?
Wil je meer weten over databasemonitoring en disasterrecovery? Neem gerust contact met ons op.
