Articoli

In questo articolo verranno trattati i due metodi di elaborazione delle query conosciuti come Row mode execution e Batch mode execution per SQL Server 2019. Verrà inoltre descritto un meccanismo per attivare Batch mode execution su SQL Server 2017 anche quando non si possono creare indici columnstore “effettivi”.

Row mode execution

Row mode execution è un metodo di elaborazione delle query utilizzato con le tabelle tradizionali disk-based, in cui i dati vengono archiviati in formato riga. Le tabelle che utilizzano questo tradizionale formato di archiviazione vengono anche dette “rowstore table”. Quando una query viene eseguita e accede ai dati archiviati in formato riga, gli operatori previsti nel piano di esecuzione leggono ogni riga richiesta dalla query. Da ogni riga letta, SQL Server recupera quindi le colonne necessarie, specificate nell’istruzione SELECT, in un predicato di JOIN, in un predicato di filtro, ecc..

Come già annunciato allo scorso Ignite, una delle nuove (tra le tante) feature di SQL Server 2019 accolta con ovazione dei presenti è la possibilità di ottenere informazioni più complete rispetto al tanto odiato messaggio

La buona notizia è che è possibile abilitare la stessa funzionalità anche su SQL Server 2017 (e con la SP2 su SQL Server 2016) installando la CU12 e abilitando trace flag 460.

Qualche settimana fa un collega mi ha sottoposto un quesito la cui risposta coinvolge alcuni concetti molto interessanti. La domanda più o meno era:

SQL Server mi dice che manca un indice, l’ho creato. Perchè eseguendo una query su sys.dm_db_missing_index_details trovo ancora l’indice come mancante? Come dico a SQL di aggiornare la DMV?

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!”.