SQL Server Performance Blog where milliseconds matter

Buongiorno a tutti e nuovamente ben ritrovati! Oggi vi volevo parlare di alcuni concetti basilari relativi ai database relazionali che sono assolutamente da sapere. Parleremo di Transazioni , di lock e anche di un tipo particolare di lock detto deadlock . Vi racconterò un po di teoria ma non temete: come al solito cercherò di essere quanto più possibile chiaro! Sei pronti? Allora buona lettura! Diciamo subito cos'è una transazione. Una transazione è una sequenza di operazioni che, se giunta a termine senza errori, produce una variazione di stato nella nostra base dati . Ad esempio: BEGIN TRAN INSERT INTO TABELLA_A (CAMPO1, CAMPO2) VALUES ('VAL1','VAL2') INSERT INTO TABELLA_B(CAMPO1,CAMPO2,CAMPO3) VAULES ('VAL1','VAL2','VAL3') COMMIT oppure INSERT INTO TABELLA_A (CAMPO1, CAMPO2) VALUES ('VAL1','VAL2') Nel primo caso parliamo di transazione esplicita , nel secondo invece

Carissimi lettori! Oggi, torniamo a parlare di ottimizzazione ! Già perché un sistema veloce è anche sinonimo di sistema di qualità! Comprereste da Amazon se per aggiungere un articolo nel carrello impiegereste due o tre minuti? Non credo! Si parte! Con questo articolo vorrei sottolineare questo aspetto non tanto conosciuto: quando scriviamo le nostre Query (a proposito da pronunciarsi “Quiri”) è meglio specificare sempre lo Schema (pronunciato “Schima”) In pratica: SELECT * FROM DBO.TABELLA Anziché: SELECT * FROM TABELLA Questo per due motivi: Primo motivo Se non specifichiamo lo schema sarà SQL Server a doverlo fare.  Dovrà fare un paio di verifiche veloci che sono: Determinare lo schema di default e verificare se esiste una tabella con quel nome nello schema di default Se non esiste nessuna tabella allora dovrà anche verificare se una tabella con quel nome è presente nello schema dbo. Normalmente sono operazioni svolte molto

A volte capita! Cambia il server dove è installato il nostro applicativo. Era presente una versione di SQL Server in italiano (d’altronde siamo in Italia) e ce ne troviamo una in inglese. OMG! Tutto bene? Non proprio! La prima cosa che succede è che le nostre procedure che hanno a che fare con le date non funzionano più . Già, se ci pensate bene in Italia abbiamo il formato gg/mm/aaaa In lingua inglese invece la data segue con questo formato mm/aa/aaa In pratica se cerchiamo di convertire la data sotto dopo il cambio server il cast restituisce errore: SELECT CAST('22/10/2019' AS DATETIME) Andrebbe infatti bene se avessimo scritto: SELECT CAST('10/22/2019' AS DATETIME) Occorre cambiare le impostazioni relative alla lingua . Semplice! Ecco come! Fate tasto destro sulle proprietà del server. Scegliete la pagina advanced . Cambiate infine le impostazioni del Default Language da English a italiano

Carissimi lettori di nuovo ben trovati! Nello scorso articolo ( Qui ) abbiamo imparato ad utilizzare gli Extended Event di SQL Server per tracciare in profondità eventi non disponibili tramite il Profiler. Lo abbiamo fatto per utilizare oggi questo stesso metodo così da raccontarvi cosa succede durante il processo di recovery del database . Cercheremo di raccontarlo nel modo più semplice possibile al costo di tralasciare qualche aspetto tecnico che magari riprenderemo in futuro. Buona lettura!    Database recovery e le fasi di Analysis, Redo e Undo Se avete avuto la necessità di eseguire un riavvio della istanza di SQL Server vi sarete accorti sicuramente di quanto tempo questo processo impieghi . Ma quali operazioni SQL Server effettua durante questo fondamentale processo? Per scoprirlo (e per effettuare assieme questa prova) occorrerà crearsi un Extended Event il quale estragga i seguenti tre eventi:  database_recovery_progress_report database_recovery_times  dat

Carissimi lettori, Spero vi sia piaciuto l'ultimo l'articolo! Non vi nascondo che mi ha occupato per un certo numero di ore. Oggi cambiamo un attimo argomento per parlare di Extended Event . Lo facciamo perchè ci servirà per poter introdurre i prossimi articoli. Si tratta infatti di una funzionalità molto potente nata addirittura ai tempi di SQL Server 2008 ed introdotta per sostiture il tool SQL Server profiler . All'epoca purtroppo non ottenne il successo sperato da Microsoft e ciò molto probabilmente fu dovuto alla mancanza di una interfaccia grafica che ne rendesse agevole la configurazione che  al tempo doveva essere creata a mano tramite uno script in T-SQL. L'interfaccia grafica vide la luce solamente con l'introduzione di SQL Server 2012. Nel frattempo versione dopo versione sono aumentati gli eventi che è possibile tracciare passando dai 180 disponibili in SQL Server 2018 ai 1320 della versione 2016 di SQL Server. Parecchi di questi eventi non

Carissimi lettori, Oggi vorrei aprire una parentesi nella nostra carrellata di articoli che trattano delle novità di SQL Server 2019 per parlarvi di una domanda interessante che mi è stata posta qualche giorno fa. La domanda era più o meno questa: Cosa succede quando eseguo un UPDATE che non va a aggiornare nessun dato perchè il suo valore è già quello che io voglio impostare? Un update che non aggiorna nessuna riga Per fare un esempio prendiamo la tabella creata nello scorso articolo. Supponiamo quindi che la colonna NOME abbia già il valore "LUCA" Il nostro primo UPDATE sarebbe questo: UPDATE ELENCOVENDITE SET CLIENTE = 'HHH' WHERE ID = 8 La domanda continuava chiedendo se, ai fini delle prestazioni , in questo caso non fosse meglio aggiungere una condizione nella clausola WHERE: UPDATE ELENCOVENDITE SET CLIENTE = 'HHH' WHERE ID = 8 AND CLIENTE<> 'HHH' Siete pronti per vedere cosa acca

Ciao a tutti! Per introdurre la novità di cui parleremo oggi partiamo da un esempio. Supponiamo abbiate una tabella dentro al vostro gestionale in cui vengano registrate tutte le vendite effettuate. Concettualmente le colonne di questa tabella saranno: il cliente che effettua l'acquisto, l'articolo che il cliente acquista, la quantità ed il prezzo. Supponiamo per semplicità che tale tabella abbia questa struttura: CREATE TABLE ELENCOVENDITE (ID INT IDENTITY(1,1), CLIENTE VARCHAR(80), ARTICOLO VARCHAR(80), QUANTITA FLOAT, PREZZO FLOAT) Supponiamo adesso che vogliate sapere il numero di articoli acquistati per ogni cliente. Semplice direte voi scrivendo il comando sotto: SELECT COUNT( DISTINCT (CLIENTE)) FROM ELENCOVENDITE Bravi risposta esatta! Non vi stupirà però sapere che questa operazione, che in apparenza sembra essere così semplice, richiede invece tante risorse. Richiede infatti di scorrere tutte le righe della nostra tabella.

Ciao a tutti! Ben ritrovati. Siete pronti per continuare la carrellata delle novità introdotte da SQL Server 2019? Già perchè se avete letto i precendenti articoli ormai saprete che sono tante. Noi, come al solito, ci focalizzeremo sulla novità che ci consentono di migliorare le prestazioni ed quindi anche la novità vedremo ci consentità di ottenere prestazioni maggiori! Parliamo di Batch Mode on RowStore . Prima però occorre fare un passo indietro per vedere che cos'è un Batch! Già cos'è un Batch? Detto in modo semplice un batch è una struttura ampia 64 KB che al suo interno contiene un gruppo di righe che vanno a 64 a 900 a seconda del numero di colonne di cui sono composte. Internamente la sua struttura è fatta così: i dati sono contenuti un Column Vector uno per ogni colonna e poi prefense anche n qualifyng row vector dentro al quale viene memorizzato per ogni riga che questa fa ancora parte del batch oppure se è stata cancellata. Quali sono i vantaggi da

Ciao a tutti, Voglio ringraziare per le numerose visite a questo blog. Grazie inoltre per le domande che mi sono pervenute, cercherò di dare un risposta a tutti quelli che mi hanno scritto. Promesso! Anche oggi volevo mostrarvi una miglioria ed un altro motivo in più per upgradare a SQL Server 2019. Questo volta parliamo di User Defined function conosciute anche con l'acronimo di UDF . Diciamo subito che in SQL Server possiamo avere tipi diversi di UDF: Le funzioni scalari ovvero quello che ritornano un solo valore Le funzioni multi-statement table valued  dette TVF che ritornano più valori Le funzioni inline table valued che sono ottimizzate per le prestazioni. Oggi parleremo solo delle funzioni scalari . Una esempio può essere la seguente funzione scalare: CREATE OR ALTER FUNCTION F_GET_PREZZO (@ARTID INTEGER) RETURNS FLOAT AS BEGIN DECLARE @Prezzo FLOAT SELECT @Prezzo = PREZZO FROM LISTINO WHERE ARTID=@ARTID; RETURN (@Prezzo) END ; Dall&