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

“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.

Management Studio crashed 1

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

Management Studio crashed 2

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

Management Studio crashed 3

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

Management Studio crashed 4

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

Management Studio crashed 5

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.

Management Studio crashed 7

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.

Management Studio crashed 6

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

Management Studio crashed 8

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.

Chi è Emanuele Zanchettin

Emanuele Zanchettin, dopo gli studi in Ingegneria Informatica, nel 1998 inizia la sua carriera lavorativa con DB2 in ambito bancario. Dopo qualche anno, con un cambio di ambito applicativo, incontra sul suo cammino Access e Oracle. Con questi ultimi lavora per diversi anni nell'ambito del tuning per l'accesso ai dati e design del database per nuove features applicative. Dal 2007 si immerge anche nel mondo SQLServer 2K, 2005, 2008* e 201*. Non meno importante la particolare attenzione, dal 2011, ad Azure SQL Database (fu SQL Azure). Al fine di aver una maggiore capacità di valutazione e confidenza con le varie tecnologie che il mercato offre, approfondisce la propria conoscenza anche con MySQL. Ad oggi Emanuele si occupa principalmente di gestione di progetti informatici: un occhio di riguardo per la progettazione e ottimizzazione, nonchè attenzione alle performance, nell'ambito della gestione dei dati. Per non farsi mancare nulla si "sporca" le mani anche con codice .NET Completa il profilo di Emanuele, il suo impegno continuo nell'ambito delle Community: componente attivo dello staff di 1nn0va (Community Ufficiale Microsoft), organizzatore e/o speaker a conferenze locali, nazionali ed internazionali su tecnologie SQLServer e Azure SQLDatabase.

Leggi Anche

Modalità di elaborazione query e indici columnstore

In questo articolo verranno trattati i due metodi di elaborazione delle query conosciuti come Row …