SQL Server Performance Blog where milliseconds matter

Ciao a tutti! Oggi torniamo a parlare del database TEMPDB. Ne abbiamo già parlato altre volte in una serie di articoli che potete trovare qui: Confronto tra "Temp Tables" (#) e "Table Variables" (@)   Il TEMPDB e la sua configurazione.. pronti per le Ferie?   SQL Server & come spostare il database TEMPDB Cos’è il database TEMPDB? ...e quindi perché è importante. Questa volta però vi racconterò delle novità introdotte più di recente . Già perchè SQL Server con l'edizione 2019 introduce alcuni miglioramenti che sono davvero significativi in questo caso.   Memory-Optmized TempDB Metadata La feature Memory-Optmized TempDB Metadata di cui parlamiano oggi fa parte della famiglia di tecnologie dette In-Memory Database . Ma cosa significa Memory-Optmized TempDB Metadata? Cercherò di spiegarlo nel modo più semplice possibile! Dopo i numerosi articoli saprete sicuramente cos'è ed a che cosa serve il database TempDB. Sapete che è una risorsa c

Ciao a tutti carissimi lettori, Oggi cambiamo argomento continuando nel nostro percorso che ci portato in queste ultime settimane a parlare delle tante novità introdotte dalla versione 2019 di SQL Server ormai in arrivo. Premessa importante: vedete questa novità che adesso vi racconterò come l'ultima via d'uscita nel caso in cui abbiate aumentato il livello di compatibilità della vostra applicazione che si appoggia a SQL Server e vi troviate ad avere una Query che manifesta dei problemi! Parliamo infatti della introduzione di un nuovo hint da specificare alla fine della nostra Query chiamato: QUERY_OPTIMIZER_COMPATIBILITY_LEVEL_n . Microsoft stessa deve essere stata tanto convinta dell'utilità di questo hint da introdurlo anche su SQL Server 2017 previo aggiornamento al CU (cumulative upadate) 10 tramite la patch KB4342424 .   Ma vediamo di cosa si tratta.   QUERY_OPTIMIZER_COMPATIBILITY_LEVEL_n  Attraverso l'hint QUERY_OPTIMIZER_COMPATIBILITY_LEVEL

Cari lettori, Eccoci di nuovo assieme per continuare il discorso inziato nel precedente articolo che trovate Qui In precedenza vi avevo raccontato la storia delle Table Variables ma anche delle loro limitazioni . Ora però è il momento di raccontarvi le novità che accompagnano l'uscita della versione 2019 di SQL Server. Siete pronti? Mettetevi comodi che si parte!   Table Variables deferred compilation   Diamo subito un nome alla novità introdotta da SQL Server 2019 che riguarda le Table Variables: la Table Variables deferred compilation Come spiega il nome la compilazione delle Table Variables diventa Differita. Differita nel senso che avviene non al momento in cui la tabella viene creata bensì viene posticipata (differita) al momento in cui la tabella viene utilizzata nella nostra Query . Più in dettaglio, la stima della cardinalità avviene al primo utilizzo dopodichè non avverrà nessuna altra ricompilazione. Di fatto è quindi un compromesso tra il ricompilare la

Carissimi lettori, Oggi volevo tornare a parlarvi delle table variables . Ne avevamo già discusso delle Table variables ad inizio mese Qui quando le avevamo confrontate con le Temp Tables. Questa volta però volevo parlarvi delle loro storia , raccontarvi della loro evoluzione nel corso del tempo e delle versioni di SQL Server. Parlaremo poi anche del trace flag 2453 che ci permetterà di avere in alcuni casi prestazioni maggiori. Ma adesso partiamo!   Table variables Le tabelle di tipo Table variables furono introdotte addirittura ai tempi di SQL Server 2000. Create per gestire i dati temporanei in modo più veloce rispetto alle Temp Tables, fu scelto di limitare le ricompilazioni e di non dotarle di statistiche. Di fatto l'idea si rivelò vincente ... a metà! Se infatti memorizzate in una Table Variables solamente poche righe avrete prestazioni ottime. Se però avete necessità di memorizzarne di più vedrete che le prestazioni caleranno. Caleranno proprio a cau

Ehi ragazzi! La domanda è di quelle importanti! Siete pronti per scoprire tutto ma proprio tutto sulla clausola NOLOCK?   Se la riposta è si, allora seguitemi! Oggi ne spiegheremo il funzionamento in maniera approfondita. Faremo una introduzione al concetto di tipi di LOCK Ed infine vedremo come mai una SELECT ne può bloccare un'altra. Non vi nascondo che il motivo di questo articolo è fare chiarezza. Su questo argomento si sentono spesso affermazioni “curiose” ma tra le tante questa è la prima: “ uso la SELECT con l’opzione WITH(LOCK) così non blocco le altre tabelle ”.   Ma, è proprio vero quanto affermato? Beh oggi facciamo il punto!   Buona lettura!     La clausola NOLOCK Diciamo subito per iniziare che cos’è la NOLOCK. NOLOCK è il nome di una clausola che è possibile specificare all’interno di uno statement di tipo SELECT utilizzando la seguente sintassi: SELECT * FROM TABELLA WITH (NOLOCK) Si noti che non possiamo utilizzare questa cl

Ben ritrovati! Nello scorso articolo che trovate qui vi avevo raccontato brevemente cosa sono gli indici tipo columnstore parlandovi anche della loro evoluzione con il succedersi delle versioni di SQL Server. Avevamo poi discusso delle novità introdotte da SQL Server 2019 relative a questo tipo di indici. Oggi continuiamo a parlare di indici parlando di un'altra novità introdotta anch'essa a partire dalla versione di SQL Server in uscita. Parliamo di Resumable Online Index Creation . Resumable Online Index Creation Per introdurre l'argomento diciamo che SQL Server 2017 aveva introdotto la possibilità di mettere in pausa (pause) e di riprendere (resume) il rebuild online di un indice. L'utilità di questa feature ha senso quando si parla di database di dimensioni considerevoli come ad esempio nei datawarehouse dove questa è un operazione che può durare ore. SQL Server 2019 introduce la stessa funzionalità di pause/resume anche durante la creazione dell'ind

Ciao a tutti, Oggi articoli leggero leggero. Voglio parlarvi di un comando che potrebbe tornarvi utile in molte molte occasioni. Avete presente quando avete il vostro bel database del cliente sottomano ed avreste bisogno di averne uno con la stessa identica struttura ma vuoto . Fino ad adesso cosa avreste fatto? Beh avreste percorso l'unica strada percorribile... inziare a svuotare le tabelle una per una togliendo o disabilitando tutti i constraint. Operazione sinceramente tediosa! E allora? Bhe dovete sapere che a partire da SQL Server 2014 SP2 è stato introdotto un nuovo comando che si chiama: DBCC CLONEDATABASE (DB_ORIGINALE,DB_DESTINAZIONE) Avrete già capito dacchè il nome racconta tutto. Questo comando appunto clona la struttura del database senza copiare i dati . WOW! Diciamo che ovviamente il database sorgente dovrà essere leggibile ed integro. Ma proviamolo!   Il test   Digitiamo il comando T-SQL sopra: DBCC CLONEDATABASE('TEST_TEMP

Carissimi lettori, Oggi nuovo articolo, il secondo riguardante le novità introdotte dal nuovo SQL Server 2019 . Se vi siete persi il precedente articolo in cui raccontavamo della clausola OPTIMIZE_FOR_SEQUENTIAL_KEY fate click qui: The last page insert latch contention issue e la clausola OPTIMIZE FOR SEQUENTIAL KEY di SQL Server 2019 RC1 (parte 3) Oggi parliamo invece di un altra novità ovvero del rebuild online degli indici columnstore . Siete pronti? Via!   Rebuild online degli indici columnstore Già, ma cosa sono gli indici columnstore? Facciamo una brevissima e semplice introduzione per spiegarne la sola logica di base. Non ci addentreremo per questa volta in nessun dettaglio tecnico. Gli indici columnstore sono un nuovo tipo di indice (introdotto per la verità già da un molti anni con la versione 2012 di SQL Server) la cui caratteristica principale è quella di  memorizzare i dati non per riga ma bensì per colonna :     Questo tipo di indice fu sviluppato per

Carissimi lettori, Eccoci nuovamente qui per un articolo particolamente intenso. Con oggi terminiamo questa serie di articoli legati alla problematica detta last page insert contention issue allacciandoci ad un altro arogmento che vi prometto sarà ugualmente se non più interessante. Come saprete già, è uscita da pochi giorni la versione Release Candidate 1 di SQL Server 2019 . E' stata anticipata da ben 8 Common Technology Preview (CTP) che ci hanno mostrato un assaggio delle nuove feature che la nuova versione ci porterà. Iniziamo quindi ad analizzare le novità che ci porterà SQL Server 2019. Una di esse è proprio dedicata alla riduzione del fenomeno che stiamo analizzando in questa ultima serie di articoli.   Questa nuova feature è detta OPTIMIZE FOR SEQUENTIAL KEY ed è in realtà una clausola che è possibile specificare durante la creazione di un indice .   Proviamola!   OPTIMIZE FOR SEQUENTIAL KEY Feature  Impostiamo per prima