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.

Qui trovate tutti i dettagli.

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?

La risposta alla domanda è abbastanza semplice: una DMV non può essere aggiornata dall’utente. Unica componente con diritti di “scrittura” di questa particolare DMV è il Query Optimizer, che però va ad “aggiungere” informazioni. Se invece si vuole “svuotare” il contenuto della DMV.. beh.. non ci sono santi: serve riavviare l’istanza del server (come peraltro chiaramente riportato nella documentazione online)

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.

Proprio recentemente mi sono imbattuto in una serie di batch (dalle semplici query a complesse procedure) dove non si era prestata la dovuta attenzione all’utilizzo dei tipi dato (ad esempio nella definizione di variabili e costanti, ma anche nelle colonne delle stesse tabelle), andando di fatto a creare qualche inconveniente, oltre che di mera natura estetica (e quindi di qualità del codice), anche (e soprattutto) di natura prestazionale. Buona parte di questi problemi era dovuta all’utilizzo frequente delle funzioni di conversione CAST e CONVERT (dovuti a probabili errori di modellazione delle tabelle come ad esempio stessa colonna in due tabelle differenti ma con differente tipo dato), ma la parte più critica e rilevante era dovuta  alla presenza di una miriade di conversioni implicite.