SQL Server Performance Blog where milliseconds matter

Carissimi lettori, E' fine luglio e con questo articolo la redazione si prende un breve periodo di pausa per ricaricare le energie. Parafrasando il titolo originale, oggi parliamo di un argomento un po diverso da solito. Approcciamo il mondo misterioso e sotterraneo degli hacker facendovi vedere una delle tecniche usate per accedere a fonti dati a cui non si avrebbe il diritto ad accedere. Però mi raccomando! lo scrivo in maiuscolo " TRY ONLY AT HOME "! Non provate mai ad accedere a dati di cui non avete l'autorizzazione per accedere: Per prima cosa quasi certamente vi scoprirebbero inoltre, essendo ovviamente illegale si richiano sanzioni legali. LA SQL INJECTION La SQL Injection è una tecnica che consiste nell'introdurre codice malevolo all'interno delle stringhe SQL. E' una delle tecniche di hacking web più comuni. Pensate ad esempio al momento in cui un sito WEB richiede le credenziali per accedere. Tipicamente sarà presente un campo in

Cari lettori, Nell'ultimo articolo di ieri abbiamo visto come sia possibile rintracciare l'utente che ha eliminato una tabella dal database. Oggi vediamo invece come capire chi ha eliminato da una tabella alcune delle sue righe. Buona lettura! Chi è stato a cancellare le righe dalla mia tabella? Utilizziamo, come abbiamo mostrato ieri, la funzione non documentata da Microsoft fn_dblog. Attenzione: proprio perchè non documentata non vi consiglio di adoperarla all'interno delle vostre applicazioni. Questa funzione potrebbe non essere più disponibile in futuro. Vi mostro il procedumento passo passo. Per prima cosa creaimo una tabella ad esempio Movimenti e la riempiamo con alcuni dati: CREATE TABLE [Movimenti] ( [ID] INT IDENTITY, [Date] DATETIME DEFAULT GETDATE (), [importo] float ); INSERT INTO Movimenti VALUES ( '28/07/2019' ,100) INSERT INTO Movimenti VALUES ( '29/07/2019' ,125)   Poi andiamo a cancellare una riga: DELETE F

Cari lettori, Ancora grazie per le numerose visite a questo blog ...sono davvero apprezzate quindi continuate così! Lo scorso articolo sulle Query SARGABLE è stato abbastanza denso di concetti ed è stato anche il più letto...lo riprenderò andando più in dettaglio promesso! Vorrei però far trascorrere un po di tempo perchè questi concetti sedimentino.. Stasera invece vorrei parlarvi di un caso che, molto probabilmente, vi sarà capitato. Immagino anche avrà destato in voi quella sorta di panico che scaturisce in genere quando non si sa come procedere.. Immaginate di essere lì tutti concentrati nella modifica di una vostra Query sviluppata nel corso delle settimane. Bene! La eseguite "et voilà"...il messaggio parla chiaro: Messaggio 208, livello 16, stato 1, riga 1 Il nome di oggetto 'movimenti' non è valido. La tabella con i dati più importanti per la vostra azienda! e che avete sempre interrogato non esiste più ....è stata cancellata! Già,

Cari lettori, oggi si cambia argomento! Siete stati bravi: avete resistito a ben tre miei articoli sul database TEMPDB di SQL Server e quindi oggi parliamo d'altro.. Volevo infatti iniziare a parlare di come scrivere Query che siano performanti. Premetto che sarà, per forza di cose, una introduzione nella quale volutamente non scenderò in dettagli. L'obbiettivo per oggi è infatti focalizzare l'attenzione, più che altro, sui concetti principali. Ma come al solito, se avete domande, scrivetemi!   Iniziamo! Diciamo subito che una Query è performante quando sfrutta la presenza degli indici presenti sulle tabelle ; solo in questo modo infatti i dati verranno estratti "velocemente". Ovviamente possiamo creare anche tabelle prive di indici (che sono dette tabelle HEAP), in questo caso però l'unico modo per recuperare i dati sarà quello di leggere completamente la tabella. Vediamolo chiaramente con un semplice esempio: Per prima cosa creiamo una tabella PERSON

Cari lettori, Finisco con oggi il terzo e ultimo articolo sul database TEMPDB. Abbiamo già detto che cosa cos'è, a che cosa serve e perchè è importante. Abbiamo poi parlato di come impostarlo correttamente. Oggi vediamo come spostarlo da una cartella ad un altra oppure da un disco ad un altro. Perchè potrebbe essere necessario spostarlo? Potremmo aver messo il database su un disco dedicato ed il disco non è sufficientemente spazioso. Potremmo più probabilmente avere problemi di prestazioni e dopo un accurata analisi essere arrivati a capire che il collo di bottiglia è proprio il nostro TEMPDB. In questi casi una possibilità è quella di spostare il database TEMP su di un disco più veloce! A proposito oggi il miglior disco che posso consigliare è un disco con tecnologia SSD e di classe enterprise. Vediamo ora come effettuare lo spostamento del database TEMPDB.   Spostare il database TempDB Per prima cosa osserviamo di quanti files è costituito il nostro database. Dal ma

Innanzitutto grazie per le tante visualizzazioni ricevute! Anche perchè diciamocelo, siamo in un periodo, quello a ridosso delle ferie estive, che certo non invoglia letture profonde e complicate. Già certo, proprio non mi immagino qualcuno a leggere questo mio articolo sotto l’ombrellone! Cercherò quindi di essere chiaro, conciso ...insomma breve. Nello scorso articolo ho cercato di spiegare perché il database TEMPDB di SQL SERVER è importante. Oggi, per continuare questo discorso vorrei raccontarvi qualcosa su come configurarlo correttamente.    Configurare il database TempDB correttamente Premesso che è sempre preferibile farlo risiedere sul disco più veloce di cui si dispone iniziamo dicendo che per impostarlo occorre prima di tutto eseguire il SQL Server Management Studio (SMSS).  Dopo aver trovato tra i database di sistema il nostro TEMPDB fare tasto destro e scegliere la voce proprietà:   Si apre una finestra che ci mostra i due file fisici di cui è composto il database T

Cos’è il database TEMPDB? ...e quindi perché è importante. Oggi vorrei scrivere poche righe ma che siano chiare … l’arte della sintesi nasce infatti dalla conoscenza profonda della materia conosciuta! Se quindi così non è ditemelo che cercherò di migliorare.. Innanzitutto..     Cos’è il TEMPDB? Il TEMPDB è un database presente in ogni versione di SQL SERVER. Al suo interno vengono memorizzate principalmente gli oggetti interni che crea il motore del database. Questi oggetti interni sono ad esempio le tabelle di lavoro dove SQL “parcheggia” le elaborazioni intermedie durante l’esecuzione delle Query (Hash JOIN o Hash Aggregate). Nel TEMPDB ci finiscono inoltre i risultati intermedi per le query che fanno operazioni di GROUP BY, ORDER BY o nelle UNION. Ecco perché il TEMPDB è così importante. Quindi:  Se lo posizioniamo su uno Storage “lento” …lente saranno anche le Query! Se non lo configuriamo correttamente …lente saranno le Query! Il TEMPDB è inoltre una risorsa condivisa ne

Finalmente..  Questo è quello che mi sono detto mentre leggevo le novità che l'uscita della Versione 2019 di SQL Server si porterà dietro. Sicuramente, tutti coloro che per lavoro o anche solo per semplice hobby, usano SQL Server si saranno più e più volte imbattuti in questo errore: Msg 8152, Level 16, State 30, Line 3 String or binary data would be truncated. The statement has been terminated La reazione a questo errore è sempre e solo una: OK sto inserendo i dati in una tabella, sto scrivendo un testo troppo lungo rispetto alla dimensione di una colonna e mi esce l'errore. Ma quale sarà questa colonna che causa l'errore? Adesso dovrò iniziare a controllarle una ad una.. Bene! La novità è che SQL Server 2019 ci dirà qual'è la colonna in cui stiamo cercando di inserire un testo troppo lungo: Msg 2628, Level 16, State 1, Line 3 String or binary data would be truncated in table 'Demo.dbo.MyTable'. column ' MyColumn