SQL Server 2019 e l'hint QUERY_OPTIMIZER_COMPATIBILITY_LEVEL_n

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_n abbiamo la possibilità di forzare il comportamento dell'optimizer a livello della singola Query portandolo ad un livello di compatibilità diverso da quello impostato di default.
n rappresenta il livello di compatilità scelto tra i valori 100,110,120,130,140 e 150.

Già ma come si usa?
Vediamolo assieme!

Supponiamo che la vostra applicazione giri con un livello di compatilità 100 (SQL 2008/ SQL 2008 R2) e decidete che oggi è giunto il fatidico momento di aumentare il livello di compatilità ad esempio a 150.

Tutto funziona correttamente tranne che per una Query che è regredita nel senso che dopo l'aumento di livello di compatibilità impiega più tempo di prima.

Cosa potete fare?
beh, per ovviare potete aggiungere alla fine della vostra query l' hint sotto: 

OPTION(USE HINT('QUERY_OPTIMIZER_COMPATIBILITY_LEVEL_100’))
In questo modo quando la nostra Query verrà eseguita l'optimizer di SQL Server si comporterà come se la Query girasse su SQL Server 2008 e quindi con un livello di compatibilità pari a 100.

Ovviamente sottolineo nuovamente si tratta di una soluzione provvisoria.
Occorrerà infatti mettere mano alla Query ed ottimizzarla in funzione della nuova versione di SQL Server installata.
Ma come rimedio tampone da applicare al volo ...è una ottima soluzione per trarsi l'impaccio!


Alla prossima! 
Luca


Luca Biondi @ SQLServerPerformance blog!







Next post: SQL Server 2019 ed il Memory-Optimized TempDB Metadata

Previous post:Le Table Variables // Le novità introdotte con SQL Server 2019. (Parte 2)

Comments

Post a Comment

I Post più popolari

Speaking to Sql Server, sniffing the TDS protocol

Image
Hello friends!  If yesterday you read my post and found it definitely boring (for the topic of course and not for how it was written to the author 😁) well today I promise you that the topic will be much more interesting! Let's talk about Sniffing , let's talk about going to see what happens when we "log in" or when we send a Query to SQL Server.  We will do this by taking a look to the little known tabular data stream (TDS) protocol built on top of the TCP/IP protocol. Ready! The TDS protocol What is the Tabular data stream (TDS) protocol?  The TDS is the protocol used by the SQL Server client Net-Library to communicates with SQL Server . TDS is specific to SQL Server and it is a low-level protocol that specifies both commands and data in a specific arrangement.  TDS encapsulate the TCP/IP protocol. Sniffing TDS packets you can read from the network the requests that your application do to the SQL Server and read the answer .   How to Sniff data from the ne...
Read more

SQL Server, find text in a Trigger, Stored Procedures, View and Function. Two ways and what ways is better

Image
Hi guys, Welcome back! Today a light post about a question that has been asked to me several times. The question is: how to  search for text inside a trigger or a stored procedure ? We have two different ways. A first way using a system view called syscomments: SELECT obj.xtype, text , * FROM sysobjects obj JOIN syscomments com on obj.id = com.id WHERE TEXT like '%text_that_i_am_searching_for%' A second way using a system view called sql_module: SELECT o. name AS Object_Name, o. type_desc , m. definition FROM sys.sql_modules m JOIN sys.objects o ON m. object_id = o. object_id WHERE m. definition Like '%text_that_i_am_searching_for%' ;   Another question is? What differences do we have in using one way instead of the other? Which solution is better? You have to consider that the system view sys.syscomment is obsolete and will be removed sooner or later. So don't use it in production enviroiments. The sys.sql_m...
Read more

SQL Server, Avoid that damn Table Spool!

Image
Hi guys, Welcome back for another post! A light one inspired from what i do during my work: many times I optimize queries rewriting them or adding index and i like it very much! Sometimes you need to use a little imagination, but everything you learn ... sooner or later it will come in handy! Enjoy the reading mates! Avoid the Table Spool, when you can A few days ago I came across a query whose execution time was very high ... or so it was for the client complaining about the problem. Before recreating it, let's create the structures and fill the tables with some data Create table PriceList (Id int identity (1,1) primary Key ,Code Varchar (20)) Insert into PriceList (code) select top 1000 right( '0000' + cast ( row_number () over ( order by id) as varchar (4)),4) from artico Insert into PriceList (code) select top 4000 right( '1000' + cast ( row_number () over ( order by id) as varchar (4)),4) from artico Create table OrdersList (Id int identity...
Read more