Articoli

Se avete abilitato Sql Server Auditing su un database di SQL Azure, dopo averlo esportato in .bacpac, se provate ad importarlo sulla vostra istanza in locale vi troverete di fronte al seguente messaggio: Error SQL72014: .Net SqlClient Data Provider: Msg 33161, Level 15, State 1, Line 1 Database master keys without password are not supported in this version of SQL Server. Error SQL72045: Script execution error. The executed script: CREATE MASTER KEY;

Come credo alla maggior parte di voi, spesso, anche a me capita di dover mantenere codice scritto da qualcun altro. Uno degli aspetti che (ri)trovo con una certa frequenza è che, spesso, non prestiamo attenzione a come scriviamo le nostre query, sottovalutando l’impatto che queste possono avere sul nostro sistema.

C’è ancora chi si meraviglia davanti all’opzione WITH TIES.

Molti non sanno che esiste o ne sottovalutano l’utilità.

Consideriamo la query

SELECT TOP 3 Name, ListPrice
FROM SalesLT.Product
ORDER BY ListPrice ASC;

Questa query ritornerà i primi 3 articoli ordinati per ListPrice crescente.

L’opzione WITH TIES indica che, invece di restituire solo il numero richiesto di righe, la query restituirà anche tutte le righe aventi lo stesso valore dell’ultima riga in base ai criteri di ordinamento (ListPrice, nel nostro caso). Questo significa che si potrebbero ottenere più righe rispetto a quelle richieste, ma la selezione delle righe diventa di tipo deterministico (al contrario del caso precedente).

Qualche settimana fa, mentre ero al lavoro, mi sono ritrovato a dover risolvere un problema apparentemente non molto strano, ma che tuttavia nasconde qualche retroscena interessante. I fatti sono stati più o meno questi:

Circa a metà mattinata mi è stato segnalato un problema di prestazioni su uno dei sistemi che abbiamo in gestione nel nostro team di lavoro; dopo alcuni semplici controlli è stato subito chiaro che il rallentamento era sostanzialmente dovuto ad un problema di contency sul tempdb. “Beh.. abbastanza semplice!” - ho subito pensato! - “la colpa è mia perché (ahi ahi ahi) non ho ancora fatto lo split del file dati sul tempdb!”.

“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!?

“TCP Provider, error: 0 - Il computer remoto ha rifiutato la connessione di rete. Microsoft SQL Server, Error: 1225” questo semplice e significativo messaggio ci avvisa che il Server SQL, col quale stiamo cercando di collergarci, non risponde. Ci possono essere molteplici motivi di questo “disservizio”, in questo articolo viene illustrata una delle cause e la sua risoluzione.

Il SQL Server Tiger Team si sta occupando, tra le altre cose, di tenere aggiornata la lista di tutti i trace flag disponibili in SQL Server per modificare il funzionamento nel caso sia assolutamente necessario. La lista è disponibile qui:

http://aka.ms/traceflags

Occhio, come al solito, che i trace flags non sono da usare alla leggera, quindi usateli se e solo se è strettamente necessario!