SQL Server 2005 fornisce una speciale modalità di funzionamento, la Dedicated Admnistrator Connection, (in breve DAC), che permette ad un amministratore di collegarsi al DBMS anche quando i tentativi di connessione tradizionale falliscono perché, ad esempio, il server è bloccato da un numero troppo elevato di richieste pendenti, oppure ha esaurito le risorse a disposizione. In situazioni del genere, la console di emergenza consente di eseguire query diagnostiche e risolvere i problemi che impediscono il corretto funzionamento del sistema.
Per garantire che questo tipo di connessione sia sempre disponibile, SQL Server all'avvio riserva una certa quantità di memoria e risorse alla DAC, in modo da poter servire le sue richieste anche in situazioni "critiche".
Nota: a causa di questo consumo extra di risorse, la DAC in SQL Server Express di default è disabilitata; per attivarla, è necessario aggiungere il parametro di avvio -T7806 per il servizio, utilizzando il programma SQL Server Configuration Manager come indicato su MSDN (per il significato del parametro in questione, è possibile fare riferimento alla documentazione in linea) . Nelle altre versioni di SQL Server, invece, la DAC è automaticamente abilitata fin dall'installazione.
Diversamente da quanto il nome farebbe intuire, la DAC non può essere utilizzata per le normali attività di amministrazione. Essa, infatti, ha tutta una serie di limitazioni che ne restringono il campo d'azione, come vedremo meglio nel seguito; per tale motivo, deve essere considerata solo come l'ultima risorsa a disposizione, quando nessun altro tentativo di connessione al server sembra funzionare.
Caratteristiche e limitazioni
Per utilizzare la DAC è necessario essere membri del ruolo sysadmin. Inoltre, al fine di garantire che vi siano sempre risorse disponibili per la connessione, in ogni istanza di SQL Server è consentito un unico collegamento alla console per volta: se è già attiva una connessione DAC, qualsiasi nuova richiesta genererà un errore.
Per accedere alla DAC con SQL Server Management Studio non è possibile servirsi della finestra "Connect to Server" che appare quando si avvia il programma: l'Object Explorer, infatti, non supporta la connessione tramite DAC. Si deve, invece, utilizzare la finestra delle query, accessibile facendo clic sul pulsante "Database Engine Query" nella barra degli strumenti.
In questo modo, apparirà la finestra di dialogo "Connect to Database Engine", in cui è possibile attivare la console di emergenza specificando ADMIN:serverinstance come nome del server a cui connettersi.
Secondo l'impostazione predefinita, la DAC consente solo connessioni locali. Per abilitare il collegamento anche da postazioni remote, è necessario eseguire i alcuni comandi sull'istanza a cui si vuole accedere:
sp_configure 'remote admin connections', 1; GO RECONFIGURE; GO
Nel caso in cui si vogliano disabilitare le connessioni remote, si devono ripetere le istruzioni sopra riportate, inserendo il valore 0, che sta per "falso", al posto di 1, che sta per "vero".
Come accennato all'inizio, è bene tenere presente che la DAC non può in alcun modo sostituire una normale connessione al server. Innanzi tutto, si può interagire con essa esclusivamente attraverso la finestra delle query, quindi solo eseguendo comandi T-SQL; non sono previste modalità di utilizzo tramite interfaccia grafica. Inoltre, per garantire la sua disponibilità, SQL Server assegna risorse limitate all'elaborazione dei comandi eseguiti sulla connessione DAC, in modo che un suo utilizzo errato non possa peggiorare una situazione già compromessa.
Generalmente, queste risorse sono sufficienti solo per semplici funzioni di diagnostica e risoluzione di problemi. Ad esempio, non è consentito eseguire query parallele o attività che vengono svolte da più thread, tra cui le operazioni BACKUP e RESTORE. Altri tipi di comandi, come DBCC CHECKDB o DBCC SHRINKDATABASE, ma anche complesse giunzioni su tabelle molto grandi, sebbene teoricamente consentite, andrebbero evitate perché potrebbero aggravare i problemi già esistenti sul server.
In situazioni particolarmente critiche, la connessione tramite DAC potrebbe non funzionare, oppure rivelarsi insufficiente per risolvere i problemi del DBMS: in questo caso, l'unica soluzione consiste nel riavviare l'istanza di SQL Server.
Esempio di utilizzo
Esaminiamo un possibile scenario di utilizzo della DAC. Anzitutto, creiamo un database di nome Rubrica contenente la tabella Contatti, su cui eseguiremo le nostre prove (possiamo utilizzare utilizziamo lo script in allegato Create.sql).
Ora supponiamo che un incauto utente abbia avviato una serie di comandi T-SQL che hanno bloccato l'esecuzione delle altre operazioni. Per esemplificare questa situazione, digitiamo le seguenti istruzioni nella finestra delle query:
USE Rubrica
GO
BEGIN TRANSACTION
DECLARE @i INT
SET @i = 0
WHILE (@i < 10)
BEGIN
INSERT INTO Contatti(Nome, Citta) VALUES('Nome ' + STR(@i), 'Città ' + STR(@i));
END
COMMIT TRANSACTION
GO
Come si può vedere, il ciclo WHILE non ha soluzione di continuità, quindi la transazione rimane aperta, continuando ad inserire nuovi record nella tabella Contatti. Se controlliamo la parte bassa della finestra di SQL Server Management Studio, troveremo l'ID che identifica la sessione in esecuzione (nel nostro caso 53).
Teniamo a mente questo valore, perché ci servirà in seguito. A questo punto apriamo un'altra finestra e cerchiamo di eseguire una SELECT sulla tabella Contatti:
USE Rubrica GO SELECT * FROM Contatti
La query resta in esecuzione, senza fornire alcun risultato; essa, infatti, sta aspettando che venga chiusa la transazione avviata nell'altra finestra . Anche in questo caso verifichiamo quale ID è stato assegnato alla sessione (ad esempio 54). Perché l'elaborazione possa andare avanti, è necessario forzare la terminazione del processo che sta eseguendo gli inserimenti.
Prima di proseguire, è bene precisare che, nella situazione descritta, sarebbe comunque possibile collegarsi al DBMS in modo tradizionale. Di conseguenza, per trovarsi in uno scenario che giustifichi l'uso della DAC, bisogna immaginare che, insieme ai comandi incriminati, il server si trovi ad eseguire anche numerose operazioni complesse, che magari riguardano altri database (backup, costruzione di indici Full-Text, generazione di report, etc.): in questo contesto, poiché la transazione rimasta aperta continua a consumare risorse di elaborazione, il DBMS potrebbe effettivamente non essere in grado di accettare nuove connessioni.
È in una situazione del genere che la DAC può venirci in aiuto. Colleghiamoci alla console di emergenza seguendo le istruzioni sopra riportate, quindi identifichiamo la sessione che sta bloccando il DBMS: allo scopo, utilizziamo la vista dinamica di sistema sys.dm_exec_requests, che restituisce una riga per ogni richiesta in esecuzione in SQL Server. Tra le informazioni fornite, c'è anche una colonna di nome blocking_session_id la quale, se diversa da 0, rappresenta l'ID della sessione che sta bloccando la richiesta corrispondente. Eseguiamo quindi i seguenti comandi T-SQL:
USE Rubrica GO SELECT session_id, command, blocking_session_id FROM sys.dm_exec_requests WHERE blocking_session_id > 0
Nel riquadro dei risultati dovremmo ottenere qualcosa del tipo:
session_id command blocking_session_id ---------- ------------- ------------------- 54 SELECT 53
I dati vanno interpretati nel modo seguente: la sessione con ID 54, ovvero quella che sta tentando di eseguire l'istruzione SELECT, è bloccata in attesa del completamento della sessione con ID 53, responsabile degli inserimenti senza fine. Appare evidente qual è l'azione da intraprendere: bisogna terminare la sessione 53, causando il rollback della transazione e liberando le risorse occupate (compreso il lock sulla tabella), in modo che l'istruzione SELECT possa essere eseguita correttamente. Per ottenere questo risultato, è sufficiente eseguire il comando:
KILL <id_sessione>
nel nostro caso:
KILL 53
Dopo alcuni istanti di elaborazione, a seconda del tempo per cui è stato eseguito il ciclo WHILE (necessari per annullare gli inserimenti), la sessione 53 sarà terminata. Se ora ci riportiamo nella finestra con l'istruzione SELECT, possiamo osservare che essa è stata portata a compimento: nella barra di stato, infatti, è apparso il messaggio "Query executed successfully".
Tutti i comandi T-SQL e le interrogazioni presentate sono disponibili nel file allegato.
Conclusioni
La DAC si rivela uno strumento molto utile ai DBA per ripristinare le funzionalità del sistema senza arrivare al riavvio del server. Non bisogna però abusarne: si deve usare la DAC solo quando i tentativi di connessione tradizionale sono falliti.
È necessario tenere presente che, se si è stati costretti ad utilizzare tale console, significa che il server è in condizioni critiche, perciò eseguendo le operazioni sbagliate (ad esempio comandi T-SQL molto avidi di risorse, come DBCC CHECKDB), è addirittura possibile aggravare la situazione, causando il blocco della DAC stessa e, se si arriva a questo punto, l'unica soluzione che rimane è il riavvio del servizio di SQL Server.
