“SQL Server Management Studio ha smesso di funzionare”, ho perso lo script che stavo scrivendo?

“SQL Server Management Studio ha smesso di funzionare”, a volte succede di ottenere a video questo messaggio poco simpatico.

Nulla di grave, “basta solo” riavviare il programma.

Ed ecco che una volta riavviato SSMS alcun file è stato recuperato … GRRRRRR!!!!

La cosa meno divertente, quindi, è scoprire che la query/procedura che si stava scrivendo e provando, magari da qualche ora, è andata persa. Ovvero perse le ultime modifiche non salvate .. come dici!? non hai salvato lo script SQL prima di eseguirlo!? Ahhh, non hai proprio salvato nemmeno una volta!?

Allora vediamo cosa si può fare .. se lo script non l’hai nemmeno mai eseguito .. allora armati si santa pazienza e rimettiti a scrivere tutto da zero. Vedrai che dopo aver perso qualche script e ora di lavoro … cambierai le tue abitudini.

Solitamente quando si scrive uno script/procedura si dovrebbe partire da una query semplice e man mano la si perfeziona eseguendola di volta in volta. Il fatto che non viene salvato lo script su file non è una best practice. Nel mio caso, facendo molti script di estrazione/elaborazione dati per effettuare controlli o quadrature estemporanee, mi troverei a breve con molti file “temporanei” e inutili.

C’è una buona notizia! Esiste una soluzione per recuperare lo script potenzialmente perso.
Alla fine ci basterebbe recuperare la query eseguita di recente, per fare questo ci vengono in aiuto le statistiche delle query.

SELECT *
FROM sys.dm_exec_query_stats


Otteniamo le informazioni sulle statistiche, ma non ancora lo statement SQL in chiaro. Con il campo sql_handle è possibile recuperare lo statement SQL che è stato eseguito per lo specifico piano di esecuzione.
Per estrarre l’informazione necessaria esiste un’apposita funzione di sistema:

sys.fn_get_sql()


Attenzione che non è utilizzabile semplicemente inline, infatti in fase di esecuzione otteniamo un errore.

SELECT sys.fn_get_sql(sql_handle)
FROM sys.dm_exec_query_stats
ORDER BY last_execution_time DESC


Lo statement va riscritto, magari inserendo una o più parole che possono individuare lo script che si stata scrivendo/provando: in questo caso la parola “SPECT00F“. Quindi vanno estratte tutte le query eseguite che hanno la parola chiave e ordinate per ora di ultima esecuzione (DESC) in modo da partire dalle più recenti. Senza filtro verranno estratte tutte le query memorizzate in SQL Server.

SELECT (SELECT text FROM sys.fn_get_sql(sql_handle)), *
FROM sys.dm_exec_query_stats A
WHERE (SELECT text FROM sys.fn_get_sql(sql_handle)) LIKE '%SPECT00F%'
ORDER BY last_execution_time DESC


Ottimo! E’ stato ottenuto il risultato desiderato: recuperato quanto più possibile il lavoro potenzialmente perso.
Con un semplice copia/incolla della cella contenente lo script ed ecco che ci si è risparmiato il tempo della riscrittura.

Per curiosità va verificata l’impostazione di autosalvataggio .. ecco era già impostato come salvataggio automatico ogni 5 minuti. Ma se SQL Server Management Studio si “schianta“, questa impostazione risulta inutile.

Se in questa fase di recupero si volesse fare le cose con stile e con un occhio alle prestazioni, ecco che possiamo riscrivere la query di estrazione in questo modo

SELECT B.text, *
FROM sys.dm_exec_query_stats A
CROSS APPLY (SELECT text FROM sys.fn_get_sql(sql_handle)) B
WHERE B.text LIKE '%SPECT00F%'
ORDER BY last_execution_time DESC


I piani di esecuzione delle due versioni dimostrano che, a parità di efficacia, possiamo essere efficienti anche per query di “recovery“.

In conclusione si può stare abbastanza tranquilli se SSMS dovesse chiudersi d’improvviso, il lavoro è potenzialmente recuperabile all’ultima esecuzione. Tuttavia è altamente consigliabile il salvataggio dello script su file.

Attenzione! I piani di esecuzione non sono stati creati a questo scopo di “recovery“, ma se dovesse essere necessario nessuno ci vieta di usarli a proprio vantaggio.