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)