Posts

Showing posts from November, 2019

Sargable Queries part 2. Examples

Image
Dear Readers, Today we return to the SARGABLE Queries topic started some days ago.   Let's take some examples of Queries that are SARGABLE and Query that are not! If you missed the first "episode" you still don't know the importance of SARGABLE Queries read my previous article  here Ready? I hear you say: yes yes.. So let's go!  Some Examples Let's create a simple test table and fill it with a bit of data: CREATE TABLE ELENCO (ID INT IDENTITY(1,1), CODICE VARCHAR(3) CONSTRAINT PK_Elenco_ID PRIMARY KEY CLUSTERED (id)) The ID field is self-incrementing and is the clustered index. As a first example , let's write one of the simpler Queries SELECT ID FROM LIST WHERE ID = 5 Let's see the execution plan: As we would expect the clustered index is used and a SEEK operation is performed. Now let's change the Query slightly: SELECT ID FROM LIST WHERE ID + 1 = 5

Write high performing query: Is your query SARGABLE?

Image
Hi Guys, Today i wanna talk about performance that is the subject I like best! . I told you about this topic a few months ago Here . However, the article was written in Italian; I decided to translate it into English for the benefit of all. I hope you like it! Introduction: When a Query is a performing Query?   First concept! A Query is a performing Query when it takes advantage of the presence of the indexes present on the tables. Only in this way infact data will be extracted fast Obviously we can create tables without indexes (called HEAP tables) but in this case the only way to extract data will be to read the table entirely. This concept must be clear! Let's see it through a simple example: Create a PERSON table with these three columns: ID, FIRSTNAME and LASTNAME. Then we perform this simple query: SELECT FIRSTNAME FROM PERSON WHERE FIRSTNAME = 'LUCA'   If we look at the execution plan, we immediately see that

SQL Server 2019 and the Accelerated Database Recovery

Image
Hi Guys, First of all thanks for the many visits to this blog! These are really appreciated! Today I want to tell you about another important feature introduced by SQL Server 2019 called Accelerated Database Recovery .  Are you ready? Let's start! Introduction A few weeks ago we already told about Database Recovery ( Here ). We had analyzed what happens when the SQL Server engine crashes. We did this by intentionally crashing SQL Server and then analyzing the situation through extended events . We also looked at the various phases that SQL Server takes in order to restart. In short, these three phases are: 1.Analysis :  During this phase the transaction log is read forward from the last checkpoint to determine then oldest dirty page. Is also determined the status of all active transactions which will fall into one of two cases: Committed to the log but not already written to the database (this transations need to be redone) Uncommitted or already ro

SQL Server, the Parametrization and the Parameter Sniffing

Image
Hi Guys, What I want to do today is an experiment . In fact this is my first article written in English. I don't know at the moment if it will be the last. But what is certain is that, as usually, i will try to tell you each topic in a simple and clear way! Enjoy the reading! In my previous article i showed you a little tip , today instead i will tell you a little about theory. We will talk about parameterization and a phenomenon called parameter sniffing . But now to introduce the topic lets start with... The history of the execution of a Query Today's question is?   What happens when i run a query? Well, as you can imagine, solving a query is a process that requires many steps. These steps, how can be see from the drawing below, are: The Parsing phase The first of these steps is called parsing . During the parsing (the parser) checks our T-SQL String for proper syntax (eg. you write the words " SLECT " or " FRON ") At the

SQL Server, come vedere tutte le proprietà di una tabella con un solo comando

Image
Carissimi lettori, Oggi un articolo veloce veloce! Vi faccio vedere un piccolo tips che risulta essere molto comodo in tante situazioni. Quante volte avete avuto bisogno di sapere da quali colonne è composto una tabella , quante volte poi un attimo dopo aver avuto bisogno di sapere quali colonne accettano il null o meno oppure se è presente un default. Certo queste sono tutte informazioni facili da reperire ma occorre tutte le volte navigare tra i menù dell' SMSS. C'è però una modo molto più comodo e rapido . Buona lettura! La stored procedure sp_help SQL server possiede un certo numero di stored procedure a volte davvero comode. E' il caso della stored procedure sp_help. Dal management studio eseguite il comando sp_help seguito dal nome di una tabella tra apici. Ad esempio: sp_help 'Customer' Eseguitela e guardate quello che ritorna: Come vi dicevo con un solo comando abbiamo estratto un del po di informazioni. Tra l

SQL Server, The Logical Query Processing Phases. In quale ordine viene processata una Query?

Image
Carissimi lettori, Nell'articolo di oggi parleremo di " Logical Query Processing Phases " ovvero dell'ordine in cui una query viene processata internamente . Ne parliamo sia perchè è un aspetto utile da conoscere ma sopprattutto perchè ci servirà nei prossimi articoli. Se siete pronti per imparare (quasi) tutto ma proprio (quasi) tutto sull'argomento di oggi allora ... Buona lettura! Il primo concetto che occorre tenere a mente  Il primo concetto di oggi è che il linguaggio SQL (e quindi anche il nostro T-SQL) è diverso da un linguaggio di programmazione. Nei linguaggi di programmazione il codice è processato nell’ordine di cui è scritto. Nel linguaggio SQL non è così: l’ordine in cui una Query viene processata internamente è diverso da quello in cui è scritto . Diciamolo subito tutto ha inizio dalla FROM! L’esecuzione di una Query è internamente divisa in varie fasi che sono appunto dette Query Logical Processing Phases. La prima di questa f

NEWS! Edizione Speciale! SQL Server 2019 è arrivato tra di noi!

Image
Carissimi lettori, Edizione speciale! E’ di ieri 4 novembre l’annuncio da tanti atteso dell’uscita ufficiale della versione 2019 di SQL Server . L’annuncio è avvenuto in occasione del Microsoft Ignite , la conferenza annuale ospitata da Microsoft e dedicata a Developer e professionisti dell’ IT che quest’anno si tiene (dal 04 al 08 novembre) ad Orlando in Florida. La versione SQL Server 2017 viene quindi ufficiamente mandata in pensione! Assieme alla versione RTM (Release To Manufacturing) di SQL Server 2019 (Build number 15.0.2005.5) è già stato pubblicato il primo Servicing Update che porta la Build Number a 15.0.2070.41. Le novità! Delle novità che SQL Server 2019 porta in dote , specialmente quelle che riguardano le prestazioni, ne abbiamo già parlato in numerosi articoli per cui vi lascio questo elenco: SQL Server 2019 e la funzione Approx_Count_Distinct   (07 ottobre 2019) SQL Server 2019 ed il Batch Mode on Rowstore           (05 ottobre 2019) SQL

SQL Server ottimizzazioni: perchè non utilizzare l’asterisco nelle SELECT?

Image
Carissimi lettori,  E' appena iniziato Novembre noi però siamo nuovamente assieme per parlare di ottimizzazioni! Un paio di articoli fa parlavamo di quanto fosse utile indicare lo schema davanti al nome della tabella al fine di migliorare le prestazioni delle nostre Query (qui SQL Server Ottimizzazioni: non omettere il nome dello schema! (schema name resolution) ) Oggi invece parliamo di un altra ottimizzazione anch'essa facilmente implementabile. Parliamo infatti dell'utilizzo dell' asterisco (*) nelle SELECT. Mi raccomando, seguitemi numerosi! Buona lettura! Chi è senza peccato scagli la prima pietra Lo ammetto! Capita anche a me, scrivendo Query per delle interrogazioni esterporanee, di iniziare con il classico: SELECT * FROM TABELLA JOIN .... etc etc etc. Certo l'utilizzo dell'asterisco è comodo: in un colpo solo estraggo tutti le colonne della tabella . Se però la nostra query viene utilizzata ad un applicativo, magar