Livello di compatibilità ALTER DATABASE (Transact-SQL)
Si applica a:
SQL ServerAzure SQL DatabaseIstanza gestita di SQL di Azure
Imposta i comportamenti di Transact-SQL e dell'elaborazione delle query in modo che risultino compatibili con la versione specificata del motore SQL. Per altre opzioni di ALTER DATABASE, vedere ALTER DATABASE.
Per altre informazioni sulle convenzioni della sintassi, vedere Convenzioni della sintassi Transact-SQL.
Sintassi
ALTER DATABASE database_name
SET COMPATIBILITY_LEVEL = { 160 | 150 | 140 | 130 | 120 | 110 | 100 | 90 }
Nota
Per visualizzare la sintassi Transact-SQL per SQL Server 2014 (12.x) e versioni precedenti, vedere la documentazione delle versioni precedenti.
Argomenti
database_name
Nome del database da modificare.
COMPATIBILITY_LEVEL { 160 | 150 | 140 | 130 | 120 | 110 | 100 | 90 | 80 }
Versione di SQL Server con cui il database deve essere reso compatibile. È possibile configurare i valori di livello di compatibilità seguenti (non tutte le versioni supportano tutti i livelli di compatibilità elencati):
| Prodotto | Versione del motore di database | Designazione del livello di compatibilità predefinita | Valori del livello di compatibilità supportati |
|---|---|---|---|
| Database SQL di Azure | 16 | 150 | 160, 150, 140, 130, 120, 110, 100 |
| Istanza gestita di SQL di Azure | 16 | 150 | 160, 150, 140, 130, 120, 110, 100 |
| SQL Server 2022 (16.x) | 16 | 160 | 160, 150, 140, 130, 120, 110, 100 |
| SQL Server 2019 (15.x) | 15 | 150 | 150, 140, 130, 120, 110, 100 |
| SQL Server 2017 (14.x) | 14 | 140 | 140, 130, 120, 110, 100 |
| SQL Server 2016 (13.x) | 13 | 130 | 130, 120, 110, 100 |
| SQL Server 2014 (12.x) | 12 | 120 | 120, 110, 100 |
| SQL Server 2012 (11.x) | 11 | 110 | 110, 100, 90 |
| SQL Server 2008 R2 (10.50.x) | 10.5 | 100 | 100, 90, 80 |
| SQL Server 2008 (10.0.x) | 10 | 100 | 100, 90, 80 |
| SQL Server 2005 (9.x) | 9 | 90 | 90, 80 |
| SQL Server 2000 (8.x) | 8 | 80 | 80 |
Importante
I numeri di versione del motore di database per SQL Server e il database SQL di Azure non sono confrontabili tra loro e sono invece numeri di build interni per questi prodotti distinti. Il motore di database per il database SQL di Azure è basato sulla stessa codebase del motore di database di SQL Server. Soprattutto, il motore di database nel database SQL di Azure include sempre i componenti più recenti del motore di database SQL. La versione 12 del database SQL di Azure è più recente della versione 15 di SQL Server.
Procedure consigliate per aggiornare il livello di compatibilità del database
Per il flusso di lavoro consigliato per l'aggiornamento del livello di compatibilità, vedere Mantenere la stabilità delle prestazioni durante l'aggiornamento a SQL Server più recente. Inoltre, per un'esperienza assistita con l'aggiornamento del livello di compatibilità del database, vedere Aggiornamento di database mediante l'Assistente ottimizzazione query.
Osservazioni:
Per tutte le installazioni di SQL Server, il livello di compatibilità predefinito è associato alla versione del motore di database. I nuovi database vengono impostati su questo livello a meno che il model database non abbia un livello di compatibilità inferiore. Per i database collegati o ripristinati da una qualsiasi versione precedente di SQL Server, il database mantiene il livello di compatibilità esistente, se questo è almeno il livello minimo consentito per quell'istanza di SQL Server. Se si sposta un database con un livello di compatibilità inferiore a quello consentito dal motore di database, il database viene automaticamente impostato sul livello di compatibilità più basso consentito. Questo comportamento si applica sia ai database di sistema che ai database utente.
Sono previsti i comportamenti seguenti per SQL Server 2017 (14.x) quando un database è collegato o ripristinato e dopo un aggiornamento sul posto:
- Se il livello di compatibilità di un database utente era 100 o superiore prima dell'aggiornamento, rimane invariato dopo l'aggiornamento.
- Se il livello di compatibilità di un database utente è 90 prima dell'aggiornamento, nel database aggiornato viene impostato su 100, ovvero sul livello di compatibilità supportato più basso in SQL Server 2017 (14.x).
- I livelli di compatibilità dei
tempdbdatabase ,model,msdb, e delle risorse vengono impostati sul livello di compatibilità predefinito per una determinata versione motore di database. - Per il database di sistema
masterviene mantenuto il livello di compatibilità precedente l'aggiornamento. Questo non influisce sul comportamento del database utente.
Per i database esistenti in esecuzione in livelli di compatibilità inferiori, se l'applicazione non richiede l'uso dei miglioramenti disponibili solo in un livello di compatibilità superiore, un approccio valido prevede il mantenimento del livello di compatibilità del database precedente. Per i nuovi progetti di sviluppo o quando un'applicazione esistente richiede l'uso di nuove funzionalità come l'elaborazione di query intelligenti oltre a nuovi elementi di Transact-SQL, pianificare l'aggiornamento del livello di compatibilità del database a quello più recente disponibile. Per altre informazioni, vedere Livelli di compatibilità e aggiornamenti del motore di database.
Nota
Se non sono presenti oggetti utente e dipendenze, in genere è sicuro eseguire l'aggiornamento al livello di compatibilità predefinito. Per altre informazioni, vedere Consigli - database master.
Usare ALTER DATABASE per modificare il livello di compatibilità del database. L'impostazione del nuovo livello di compatibilità per un database diventa effettiva quando si esegue un comando USE <database> o quando viene elaborato un nuovo accesso con quel database come contesto di database predefinito.
Per visualizzare il livello di compatibilità corrente di un database, eseguire una query sulla colonna compatibility_level nella vista del catalogo sys.databases.
Un database di distribuzione creato in una versione precedente di SQL Server e viene aggiornato a SQL Server 2016 (13.x) RTM o Service Pack 1 ha un livello di compatibilità pari a 90, che non è supportato per altri database. Questo non ha alcun effetto sulla funzionalità della replica. L'aggiornamento a Service Pack e versioni successive di SQL Server comporterà l'aumento del livello di compatibilità del database di distribuzione in modo che corrisponda a quello del master database.
Per sfruttare in generale il livello di compatibilità del database 120 o superiore, ma al tempo stesso usare il modello di stima della cardinalità di SQL Server 2012 (11.x), che corrisponde al livello di compatibilità del database 110, vedere ALTER DATABASE SCOPED CONFIGURATION e in particolare la parola chiave LEGACY_CARDINALITY_ESTIMATION = ON.
Per determinare il livello di compatibilità corrente, eseguire una query sulla compatibility_level colonna di sys.databases.
SELECT name, compatibility_level FROM sys.databases;
Osservazioni per Azure SQL
A partire da novembre 2022 il livello di compatibilità predefinito per i database appena creati in database SQL di Azure e Istanza gestita di SQL di Azure. Microsoft non aggiorna il livello di compatibilità del database per i database esistenti. I clienti possono decidere l'approccio da adottare in base alle proprie esigenze. Microsoft consiglia vivamente ai clienti di pianificare l'aggiornamento al livello di compatibilità più recente per usare i miglioramenti più recenti dell'ottimizzazione delle query.
Per informazioni dettagliate su come valutare le variazioni delle prestazioni delle query più importanti tra i due diversi livelli di compatibilità nel database SQL di Azure, vedere Prestazioni delle query migliorate con il livello di compatibilità 130 in Database SQL di Azure. Questo articolo si riferisce al livello di compatibilità 130 e SQL Server, ma la stessa metodologia si applica agli aggiornamenti al livello 140 o superiori per SQL Server e il database SQL di Azure.
Per determinare la versione del motore di database a cui si è connessi, eseguire la query seguente.
SELECT SERVERPROPERTY('ProductVersion');
Non tutte le funzionalità che variano in base al livello di compatibilità sono supportate nel database SQL di Azure.
Livelli di compatibilità e aggiornamenti del motore di database
Il livello di compatibilità del database è uno strumento utile per la modernizzazione dei database poiché consente di aggiornare il motore di database di SQL Server e di preservare lo stato funzionale delle applicazioni che si connettono mantenendo lo stesso livello di compatibilità del database precedente all'aggiornamento. Ciò significa che è possibile eseguire l'aggiornamento da una versione precedente di SQL Server (ad esempio SQL Server 2008 (10.0.x)) a SQL Server o database SQL di Azure (incluso Istanza gestita di SQL di Azure) senza modifiche dell'applicazione (ad eccezione della connettività del database). Per altre informazioni, vedere Certificazione della compatibilità.
Se l'applicazione non richiede l'uso dei miglioramenti disponibili solo in un livello di compatibilità superiore, esso costituisce un valido approccio per aggiornare il motore di database di SQL Server e mantenere il precedente livello di compatibilità del database. Per altre informazioni sull'uso del livello di compatibilità per la compatibilità con le versioni precedenti, vedere Certificazione della compatibilità.
Livelli di compatibilità e stored procedure
Quando si esegue una stored procedure, viene usato il livello di compatibilità corrente del database in cui è definita. Se si modifica l'impostazione di compatibilità di un database, tutte le relative stored procedure vengono ricompilate automaticamente al fine di riflettere tale modifica.
Usare il livello di compatibilità per la compatibilità con le versioni precedenti
L'impostazione Livello di compatibilità database garantisce la compatibilità con le versioni precedenti di SQL Server in relazione a Transact-SQL e ai comportamenti di ottimizzazione delle query solo per il database specificato, non per l'intero server.
A partire dalla modalità di compatibilità 130, tutte le nuove funzionalità e le correzioni con effetti sul piano di query sono state aggiunte intenzionalmente solo al nuovo livello di compatibilità. In questo modo si riduce al minimo il rischio che si corre durante gli aggiornamenti di ridurre il livello delle prestazioni per modifiche apportate al piano di query potenzialmente introdotte dai nuovi comportamenti di ottimizzazione query.
Dal punto di vista dell'applicazione, usare il livello di compatibilità inferiore come percorso di migrazione più sicuro per aggirare le differenze di versione, nei comportamenti controllati dall'impostazione del livello di compatibilità pertinente. L'obiettivo dovrebbe essere sempre l'aggiornamento al livello di compatibilità più recente per ereditare alcune delle nuove funzionalità come l'elaborazione di query intelligenti, il tutto eseguito però in modo controllato.
Per altre informazioni, incluso il flusso di lavoro consigliato per l'aggiornamento del livello di compatibilità del database, vedere Procedure consigliate per l'aggiornamento del livello di compatibilità del database.
Le funzionalità non più disponibili introdotte in una determinata versione di SQL Server non sono protette dal livello di compatibilità. Questo fa riferimento alle funzionalità rimosse dal motore di database di SQL Server. Ad esempio, l'hint
FASTFIRSTROWnon è più supportato in SQL Server 2012 (11.x) ed è stato sostituito dall'hintOPTION (FAST n ). L'impostazione del livello di compatibilità del database su 110 non ripristina l'hint sospeso. Per altre informazioni sulle funzionalità non più disponibili, vedere Funzionalità del motore di database non più disponibili in SQL Server.Le modifiche che causano un'interruzione introdotte in una determinata versione di SQL Server potrebbero non essere protette dal livello di compatibilità. Ciò si riferisce alle modifiche funzionali tra le versioni del motore di database di SQL Server. Il comportamento di Transact-SQL è generalmente protetto dal livello di compatibilità. Gli oggetti di sistema modificati o rimossi non sono tuttavia protetti dal livello di compatibilità.
Un esempio di modifica che causa un'interruzione protetta dal livello di compatibilità è una conversione implicita dai tipi di dati datetime a datetime2 . Con il livello di compatibilità del database 130, in questi tipi di dati si rileva una maggiore precisione prevedendo i millisecondi frazionari, risultanti in diversi valori convertiti. Per ripristinare il comportamento di conversione precedente, impostare il livello di compatibilità del database su 120 o un livello inferiore.
Di seguito sono elencati esempi di modifiche di rilievo non protette dal livello di compatibilità:
- Nomi di colonna modificati in oggetti di sistema. In SQL Server 2012 (11.x) la colonna
single_pages_kbinsys.dm_os_sys_infoè stata rinominata inpages_kb. Indipendentemente dal livello di compatibilità, la querySELECT single_pages_kb FROM sys.dm_os_sys_infogenererà l'errore 207 (nome di colonna non valido). - Oggetti di sistema rimossi. In SQL Server 2012 (11.x) l'opzione
sp_dboptionè stata rimossa. Indipendentemente dal livello di compatibilità, l'istruzioneEXEC sp_dboption 'AdventureWorks2022', 'autoshrink', 'FALSE';genererà l'errore 2812 (Couldn't find stored procedure 'sp_dboption').
Per altre informazioni sulle modifiche di rilievo, vedere Modifiche di rilievo apportate alle funzionalità del motore di database in SQL Server 2019, Modifiche di rilievo apportate alle funzionalità del motore di database in SQL Server 2017, Modifiche di rilievo apportate alle funzionalità del motore di database in SQL Server 2016 e Modifiche di rilievo apportate alle funzionalità del motore di database in SQL Server 2014.
- Nomi di colonna modificati in oggetti di sistema. In SQL Server 2012 (11.x) la colonna
Differenze tra i livelli di compatibilità
Per tutte le installazioni di SQL Server, il livello di compatibilità predefinito è associato alla versione del motore di database, come illustrato in questa tabella. Per le nuove attività di sviluppo, pianificare sempre la certificazione delle applicazioni con il livello di compatibilità del database più recente.
La nuova sintassi Transact-SQL non viene controllata dal livello di compatibilità del database, tranne quando possono interrompere le applicazioni esistenti creando un conflitto con il codice Transact-SQL dell'utente. Queste eccezioni sono documentate nelle sezioni successive di questo articolo, che illustrano le differenze tra livelli di compatibilità specifici.
Il livello di compatibilità del database garantisce anche la compatibilità con le versioni precedenti di SQL Server, perché i database collegati o ripristinati da una versione precedente di SQL Server mantengono il livello di compatibilità esistente (se uguale o superiore al livello di compatibilità minimo consentito). Questo argomento è stato illustrato nella sezione Uso del livello di compatibilità per garantire la compatibilità con le versioni precedenti di questo articolo.
A partire dal livello di compatibilità del database 130, le nuove correzioni e funzionalità che influiscono sui piani di query sono state aggiunte solo al livello di compatibilità più recente disponibile, detto anche livello di compatibilità predefinito. In questo modo si riduce al minimo il rischio che si corre durante gli aggiornamenti di ridurre il livello delle prestazioni per modifiche apportate al piano di query potenzialmente introdotte dai nuovi comportamenti di ottimizzazione query.
Le modifiche fondamentali che influiscono sul piano aggiunte solo al livello di compatibilità predefinito di una nuova versione del motore di database sono:
Le correzioni di Query Optimizer rilasciate per le versioni precedenti di SQL Server con il flag di traccia 4199 diventano automaticamente abilitate nel livello di compatibilità predefinito di una versione più recente di SQL Server.
Si applica a: SQL Server (a partire dalla versione di SQL Server 2016 (13.x)), database SQL di Azure.
Ad esempio, quando è stato rilasciato SQL Server 2016 (13.x), tutte le correzioni di Query Optimizer rilasciate per le versioni precedenti di SQL Server (e i rispettivi livelli di compatibilità da 100 a 120) sono state abilitate automaticamente per i database che usano il livello di compatibilità predefinito di SQL Server 2016 (13.x) (130). È necessario abilitare esplicitamente solo le correzioni di Query Optimizer successive alla versione RTM.
Per abilitare le correzioni di Query Optimizer, è possibile usare i metodi seguenti:
- A livello di server, con il flag di traccia 4199.
- A livello di database, con l'opzione
QUERY_OPTIMIZER_HOTFIXESin ALTER DATABASE SCOPED CONFIGURATION (Transact-SQL). - A livello di query, con l'hint per la query
USE HINT 'ENABLE_QUERY_OPTIMIZER_HOTFIXES'modificando la query. - A livello di query, con
USE HINT 'ENABLE_QUERY_OPTIMIZER_HOTFIXES'senza modifiche al codice, usando la funzionalità Hint di Query Store (anteprima).
In un secondo momento, con il rilascio di SQL Server 2017 (14.x), tutte le correzioni di Query Optimizer rilasciate dopo la versione SQL Server 2016 (13.x) RTM sono state abilitate automaticamente per i database che usano il livello di compatibilità predefinito di SQL Server 2017 (14.x) (140). Si tratta di un comportamento cumulativo che include anche tutte le correzioni di versioni precedenti. Anche in questo caso, è necessario abilitare esplicitamente solo le correzioni di Query Optimizer successive alla versione RTM.
Nella tabella seguente viene riepilogato questo comportamento:
Versione del motore di database Livello di compatibilità del database TF 4199 Modifiche di Query Optimizer da tutti i livelli di compatibilità del database precedenti Modifiche di Query Optimizer per la versione del motore di database successiva alla versione RTM 13 (SQL Server 2016 (13.x)) Da 100 a 120
130Disattivato
Attivato
Disattivato
AttivatoDisabilitato
Attivata
Abilitato
AttivataDisabilitata
Attivata
Disabilitata
Attivata14 (SQL Server 2017 (14.x)) Da 100 a 120
130
140Disattivato
Attivato
Disattivato
Attivato
Disattivato
AttivatoDisabilitato
Attivata
Abilitato
Attivata
Abilitato
AttivataDisabilitata
Attivata
Disabilitata
Attivata
Disabilitata
Attivata15 (SQL Server 2019 (15.x)) e 12 (database SQL di Azure) Da 100 a 120
Da 130 a 140
150Disattivato
Attivato
Disattivato
Attivato
Disattivato
AttivatoDisabilitato
Attivata
Abilitato
Attivata
Abilitato
AttivataDisabilitata
Attivata
Disabilitata
Attivata
Disabilitata
Attivata16 (SQL Server 2022 (16.x)) e 12 (database SQL di Azure) Da 100 a 120
Da 130 a 150
160Disattivato
Attivato
Disattivato
Attivato
Disattivato
AttivatoDisabilitato
Attivata
Abilitato
Attivata
Abilitato
AttivataDisabilitata
Attivata
Disabilitata
Attivata
Disabilitata
AttivataQuery Optimizer corregge i risultati errati o gli errori di violazione di accesso non sono protetti dal flag di traccia 4199. Queste correzioni non sono considerate facoltative.
Le modifiche apportate allo strumento di stima della cardinalità rilasciate in SQL Server e nel database SQL di Azure sono abilitate solo nel livello di compatibilità predefinito di una nuova versione del motore di database, ma non nei livelli di compatibilità precedenti.
Ad esempio, quando è stato rilasciato SQL Server 2016 (13.x), le modifiche apportate al processo di stima della cardinalità erano disponibili solo per i database che usavano il livello di compatibilità predefinito di SQL Server 2016 (13.x) (130). I livelli di compatibilità precedenti conservavano il comportamento di stima della cardinalità disponibile prima di SQL Server 2016 (13.x).
Successivamente, quando è stato rilasciato SQL Server 2017 (14.x), le modifiche apportate al processo di stima della cardinalità erano disponibili solo per i database che usavano il livello di compatibilità predefinito di SQL Server 2017 (14.x) (140). Il livello di compatibilità del database 130 ha conservato il comportamento di stima della cardinalità di SQL Server 2016 (13.x).
Nella tabella seguente viene riepilogato questo comportamento:
Versione del motore di database Livello di compatibilità del database Modifiche nuova versione strumento di stima della cardinalità 13 (SQL Server 2016 (13.x)) < 130
130Disabled
Attivata14 (SQL Server 2017 (14.x))1 < 140
140Disabled
Attivata15 (SQL Server 2019 (15.x))1 < 150
150Disabled
Attivata16 (SQL Server 2022 (16.x))1 < 160
160Disabled
Attivata1 Applicabile anche al database SQL di Azure.
Altre differenze tra i livelli di compatibilità specifici sono descritte nelle sezioni successive di questo articolo.
Differenze tra il livello di compatibilità 150 e il livello 160
Questa sezione descrive i nuovi comportamenti introdotti con il livello di compatibilità 160.
| Impostazione del livello di compatibilità 150 o inferiore | Impostazione del livello di compatibilità 160 |
|---|---|
| Le query con parametri hanno un singolo piano di query basato sui parametri usati per la prima esecuzione. Viene memorizzato nella cache e usato un solo piano di query per tutti i valori dei parametri. Ciò può causare un piano di query inefficiente per alcuni valori del parametro, noto anche come piano sensibile ai parametri. | Le query con parametri possono avere più piani di query memorizzati nella cache per categorie di selettività diverse di un parametro. L'ottimizzazione del piano sensibile ai parametri è abilitata per impostazione predefinita nel livello di compatibilità 160. Per altre informazioni, vedere Ottimizzazione PSP. |
| La stima della cardinalità usa un solo set predefinito di presupposti del modello relativi alla distribuzione e ai modelli di utilizzo dei dati sottostanti per tutti i database e le query. L'unico modo per modificare o modificare uno di questi presupposti è quando l'utente esegue un processo manuale per indicare in modo esplicito quali presupposti del modello devono essere usati, usando hint di query. Non è possibile apportare modifiche interne a questo modello predefinito dopo la generazione di un piano di query. | La stima della cardinalità inizia con il set predefinito di presupposti del modello sui modelli di distribuzione e utilizzo dei dati sottostanti, ma dopo alcune esecuzioni per una determinata query, l'motore di database apprende quali diversi set di presupposti del modello potrebbero produrre stime più accurate e quindi regola i presupposti in uso per trovare una corrispondenza migliore con il set di dati sottoposto a query. Il feedback ce è abilitato per impostazione predefinita nel livello di compatibilità 160. Per altre informazioni, vedere Feedback ce. |
| Nessuna determinazione automatica del grado ottimale di parallelismo viene tentata dal motore di database. Per informazioni sul controllo manuale del grado massimo di parallelismo (MAXDOP) a livello di istanza, database, query o carico di lavoro, vedere Configurare l'opzione di configurazione del server max degree of parallelism | Il feedback del grado di parallelismo (DOP) migliora le prestazioni delle query identificando l'inefficienze del parallelismo per le query ripetute, in base al tempo trascorso e alle attese. Se l'uso del parallelismo è considerato inefficiente, il feedback sul grado di parallelismo riduce il grado di parallelismo per la successiva esecuzione della query, indipendentemente dal valore del grado di parallelismo configurato, e verifica se la riduzione ha migliorato l'efficienza. Il feedback DOP non è abilitato per impostazione predefinita. Per abilitare il feedback DOP, abilitare la DOP_FEEDBACK configurazione con ambito database in un database. Per altre informazioni, vedere Feedback dop. |
Differenze tra i livelli di compatibilità 140 e 150
In questa sezione vengono descritti i nuovi comportamenti introdotti con il livello di compatibilità 150.
| Livello di compatibilità 140 o inferiore | Livello di compatibilità 150 |
|---|---|
| Il data warehouse relazionale e i carichi di lavoro analitici potrebbero non essere in grado di usare indici columnstore a causa del sovraccarico OLTP, della mancanza di supporto del fornitore o di altre limitazioni. Senza indici columnstore, questi carichi di lavoro non possono trarre vantaggio dalla modalità di esecuzione batch. | La modalità di esecuzione batch è ora disponibile per i carichi di lavoro analitici senza richiedere indici columnstore. Per altre informazioni, vedere Modalità batch per rowstore. |
| Le query in modalità riga che richiedono dimensioni di concessione di memoria insufficienti che causano perdite su disco potrebbero continuare a verificarsi problemi nelle esecuzioni consecutive. | Le query in modalità riga che richiedono dimensioni di concessione di memoria insufficienti che generano perdite su disco potrebbero avere prestazioni migliori in esecuzioni consecutive. Per altre informazioni, vedere Feedback delle concessioni di memoria in modalità riga. |
| Le query in modalità riga che richiedono dimensioni di concessione di memoria eccessive che causano problemi di concorrenza potrebbero continuare ad avere problemi nelle esecuzioni consecutive. | Le query in modalità riga che richiedono dimensioni di concessione di memoria eccessive che generano problemi di concorrenza potrebbero avere una concorrenza migliorata nelle esecuzioni consecutive. Per altre informazioni, vedere Feedback delle concessioni di memoria in modalità riga. |
| Le query che fanno riferimento a funzioni definite dall'utente scalari T-SQL useranno la chiamata iterativa, senza calcolo dei costi e con esecuzione seriale imposta. | Le funzioni definite dall'utente scalari T-SQL vengono trasformate in espressioni relazionali equivalenti che vengono "rese inline" nella query chiamante, ottenendo spesso significativi miglioramenti delle prestazioni. Per altre informazioni, vedere Inlining di funzioni definite dall'utente scalari T-SQL. |
| Le variabili di tabella usano un'ipotesi fissa per la stima della cardinalità. Se il numero effettivo di righe è molto superiore al valore ipotizzato, possono esserci effetti negativi sulle prestazioni delle operazioni downstream. | I nuovi piani useranno la cardinalità effettiva della variabile tabella rilevata nella prima compilazione invece di una stima fissa. Per altre informazioni, vedere Compilazione posticipata delle variabili di tabella. |
Per altre informazioni sulle funzionalità di elaborazione delle query abilitate nel livello di compatibilità del database 150, vedere Novità di SQL Server 2019 ed Elaborazione di query intelligenti nei database SQL.
Differenze tra i livelli di compatibilità 130 e 140
In questa sezione vengono descritti i nuovi comportamenti introdotti con il livello di compatibilità 140.
| Livello di compatibilità 130 o inferiore | Livello di compatibilità 140 |
|---|---|
| Le stime della cardinalità per istruzioni che fanno riferimento a funzioni composte da più istruzioni con valori di tabella usano un'ipotesi a riga fissa. | Le stime della cardinalità per istruzioni idonee che fanno riferimento a funzioni composte da più istruzioni con valori di tabella usano la cardinalità effettiva dell'output della funzione. Questo comportamento è abilitato dall'esecuzione interleaved per funzioni composte da più istruzioni con valori di tabella. |
| Le query in modalità batch che richiedono dimensioni di concessione di memoria insufficienti che causano perdite su disco potrebbero continuare a verificarsi problemi nelle esecuzioni consecutive. | Le query in modalità batch che richiedono dimensioni di concessione di memoria insufficienti che generano perdite su disco potrebbero avere prestazioni migliori in esecuzioni consecutive. Questo comportamento è abilitato tramite i commenti della concessione di memoria della modalità batch che aggiornerà le dimensioni della concessione di memoria di un piano memorizzato nella cache se si sono verificate distribuzioni per gli operatori della modalità batch. |
| Le query in modalità batch che richiedono dimensioni di concessione di memoria eccessive che causano problemi di concorrenza potrebbero continuare ad avere problemi nelle esecuzioni consecutive. | Le query in modalità batch che richiedono dimensioni di concessione di memoria eccessive che causano problemi di concorrenza potrebbero avere un miglioramento della concorrenza nelle esecuzioni consecutive. Questo comportamento è abilitato tramite i commenti della concessione di memoria della modalità batch che aggiornerà le dimensioni della concessione di memoria di un piano memorizzato nella cache se inizialmente era richiesta una memoria di dimensioni eccessive. |
| Le query in modalità batch contenenti operatori di join sono idonee per tre algoritmi di join fisico, tra cui join annidato dei cicli, hash join e merge join. Se le stime della cardinalità non sono corrette per gli input di join, potrebbe essere selezionato un algoritmo di join inappropriato. In questo caso, le prestazioni subiranno un problema e l'algoritmo di join inappropriato rimarrà in uso fino a quando il piano memorizzato nella cache non verrà ricompilato. | Esiste un operatore di join aggiuntivo denominato join adattivo. Se le stime della cardinalità non sono corrette per l'input del join di compilazione esterno, potrebbe essere selezionato un algoritmo join non appropriato. In questo caso e l'istruzione è idonea per un join adattivo, verrà usato un ciclo annidato per gli input di join più piccoli e verrà usato un hash join per input join di dimensioni maggiori in modo dinamico senza richiedere la ricompilazione. |
| I piani semplici che fanno riferimento agli indici Columnstore non sono idonei per l'esecuzione in modalità batch. | Un piano semplice che fa riferimento agli indici Columnstore sarà eliminato e sostituito da un piano idoneo per l'esecuzione in modalità batch. |
L'operatore UDX sp_execute_external_script può essere eseguito solo in modalità riga. |
L'operatore UDX sp_execute_external_script è idoneo per l'esecuzione in modalità batch. |
| Le funzioni con valori di tabella a più istruzioni (TVFS) non hanno un'esecuzione interleaved | Esecuzione interleaved per funzioni con valori di tabella con istruzioni multiple per migliorare la qualità del piano. |
Le correzioni nel flag di traccia 4199 delle versioni precedenti di SQL Server precedenti a SQL Server 2017 sono ora abilitate per impostazione predefinita. Con la modalità di compatibilità 140, il flag di traccia 4199 continuerà a essere applicabile alle nuove correzioni di Query Optimizer rilasciate dopo SQL Server 2017. Per informazioni sul flag di traccia 4199, vedere Flag di traccia 4199.
Differenze tra i livelli di compatibilità 120 e 130
In questa sezione vengono descritti i nuovi comportamenti introdotti con il livello di compatibilità 130.
| Livello di compatibilità 120 o inferiore | Livello di compatibilità 130 |
|---|---|
| INSERT in un'istruzione INSERT-SELECT è a thread singolo. | INSERT in un'istruzione INSERT-SELECT è multithread o può avere un piano parallelo. |
| Le query in una tabella ottimizzata per la memoria vengono eseguite a thread singolo. | Le query in una tabella ottimizzata per la memoria ora possono avere piani paralleli. |
| Introduzione della stima di cardinalità di SQL 2014 CardinalityEstimationModelVersion="120" | Ulteriori miglioramenti della stima della cardinalità (CE) con il modello di stima della cardinalità 130, visibile da un piano di query. CardinalityEstimationModelVersion="130" |
Modifiche in modalità batch e modifiche in modalità riga con indici Columnstore:
|
Modifiche in modalità batch e modifiche in modalità riga con indici Columnstore:
|
| Le statistiche vengono aggiornate automaticamente. | La logica che aggiorna automaticamente le statistiche è più aggressiva nelle tabelle di grandi dimensioni. In pratica, si dovrebbero ridurre i casi in cui i clienti registrano problemi di prestazioni in termini di quey laddove le righe appena inserite vengono frequentemente sottoposte a query senza però che le statistiche siano state ancora aggiornate con i valori attuali. |
| La traccia 2371 è OFF per impostazione predefinita in SQL Server 2014 (12.x). | La traccia 2371 è ON per impostazione predefinita in SQL Server 2016 (13.x). Il flag di traccia 2371 indica allo strumento di aggiornamento delle statistiche automatico di prendere come esempio un subset di righe più piccolo ma più idoneo, in una tabella con un elevato numero di righe. Al fine di un miglioramento, è possibile includere nell'esempio più righe rispetto a quelle che sono state inserite di recente. Un altro miglioramento prevede di eseguire le query, anziché bloccarle, nello stesso momento in cui viene eseguito il processo di aggiornamento delle statistiche. |
| Per il livello 120, le statistiche vengono campionate da un processo a thread singolo. | Per il livello 130, le statistiche vengono campionate da un processo multithread (processo parallelo). |
| 253 è il limite di chiavi esterne in ingresso. | A una tabella possono fare riferimento fino a 10.000 chiavi esterne in ingresso o riferimenti simili. Per informazioni sulle restrizioni, vedere Create Foreign Key Relationships. |
| Gli algoritmi di join hash MD2, MD4, MD5, SHA e SHA1 sono consentiti. | Sono consentiti solo gli algoritmi di join hash SHA2_256 e SHA2_512. |
| SQL Server 2016 (13.x) include miglioramenti in alcune conversioni di tipi di dati e alcune operazioni (in genere non comuni). Per informazioni dettagliate, vedere Miglioramenti di SQL Server 2016 relativi alla gestione di alcuni tipi di dati e operazioni non comuni. | |
La funzione STRING_SPLIT non è disponibile. |
La funzione STRING_SPLIT è disponibile nel livello di compatibilità 130 o superiore. Se il livello di compatibilità del database è inferiore a 130, SQL Server non sarà in grado di trovare ed eseguire la funzione STRING_SPLIT. |
Le correzioni nel flag di traccia 4199 delle versioni meno recenti di SQL Server precedenti a SQL Server 2016 (13.x) sono ora abilitate per impostazione predefinita. Con la modalità di compatibilità 130, il flag di traccia 4199 continuerà a essere applicabile alle nuove correzioni di Query Optimizer rilasciate dopo SQL Server 2016 (13.x). Per usare la versione precedente di Query Optimizer nel database SQL è necessario selezionare il livello di compatibilità 110. Per informazioni sul flag di traccia 4199, vedere Flag di traccia 4199.
Differenze tra i livelli di compatibilità inferiori e il livello 120
Questa sezione descrive i nuovi comportamenti introdotti con il livello di compatibilità 120.
| Livello di compatibilità 110 o inferiore | Livello di compatibilità 120 |
|---|---|
| Viene utilizzata la versione precedente di Query Optimizer. | SQL Server 2014 (12.x) include miglioramenti sostanziali al componente per la creazione e l'ottimizzazione dei piani di query. Questa nuova funzionalità di Query Optimizer dipende dall'utilizzo del livello di compatibilità del database 120. Per sfruttare al meglio questi miglioramenti, sarebbe opportuno sviluppare le nuove applicazioni di database utilizzando il livello di compatibilità del database 120. Le applicazioni di cui si esegue la migrazione da versioni precedenti di SQL Server devono essere testate con attenzione per assicurarsi che le prestazioni vengano mantenute o migliorate. Se si verifica un calo delle prestazioni, è possibile impostare il livello di compatibilità del database su 110 o su un valore inferiore per utilizzare la metodologia precedente di Query Optimizer. Il livello di compatibilità 120 del database utilizza un nuovo strumento di stima della cardinalità ottimizzato per i carichi di lavoro OLTP e di data warehouse più recenti. Prima di impostare il livello di compatibilità del database su 110 a causa di problemi di prestazioni, vedere le indicazioni riportate nella sezione Piani di query dell'articolo Novità del motore di database di SQL Server 2014 (12.x). |
| Nei livelli di compatibilità inferiori a 120, l'impostazione della lingua viene ignorata durante la conversione di un valore date in un valore stringa. Questo comportamento è specifico solo per il tipo di data . Vedere l'esempio B nella sezione Esempi . | L'impostazione della lingua non viene ignorata durante la conversione di un valore date in un valore stringa. |
I riferimenti ricorsivi a destra di una clausola EXCEPT creano un ciclo infinito. L'esempio C nella sezione Esempi illustra questo comportamento. |
I riferimenti ricorsivi in una EXCEPT clausola generano un errore in conformità allo standard SQL ANSI. |
| L'espressione di tabella comune (CTE) ricorsiva consente l'uso di nomi colonna duplicati. | Una CTE ricorsiva non consente nomi di colonna duplicati. |
| I trigger disabilitati vengono abilitati se i trigger vengono modificati. | La modifica di un trigger non cambia lo stato (abilitato o disabilitato) del trigger. |
La clausola della tabella OUTPUT INTO ignora IDENTITY_INSERT SETTING = OFF e consente l'inserimento di valori espliciti. |
Non è possibile inserire valori espliciti per un colonna Identity in una tabella se IDENTITY_INSERT è impostato su OFF. |
Quando il contenimento del database è impostato su parziale, la convalida del campo $action nella clausola OUTPUT di un'istruzione MERGE può restituire un errore nelle regole di confronto. |
Le regole di confronto dei valori restituiti dalla clausola $action di un'istruzione MERGE sono le regole di confronto del database anziché le regole di confronto del server e non viene restituito alcun errore di conflitto tra regole di confronto. |
Tramite un'istruzione SELECT INTO viene sempre creata un'operazione di inserimento a thread singolo. |
Tramite un'istruzione SELECT INTO è possibile creare un'operazione di inserimento parallela. Quando si inserisce un numero elevato di righe, con un'operazione parallela è possibile migliorare le prestazioni. |
Differenze tra i livelli di compatibilità inferiori e i livelli 100 e 110
Questa sezione descrive i nuovi comportamenti introdotti con il livello di compatibilità 110. Questa sezione si applica anche ai livelli di compatibilità superiori a 110.
| Livello di compatibilità 100 o inferiore | Impostazione del livello di compatibilità 110 o inferiore |
|---|---|
| Gli oggetti di database CLR (Common Language Runtime) vengono eseguiti con la versione 4 di CLR. Non sono tuttavia presenti alcune modifiche del comportamento introdotte con la versione 4 di CLR. Per altre informazioni, vedere Novità dell'integrazione CLR. | Gli oggetti di database CLR vengono eseguiti con la versione 4 di CLR. |
| Le funzioni XQuery string-length e substring considerano ogni surrogato come due caratteri. | Le funzioni XQuery string-length e substring considerano ogni surrogato come un carattere. |
La parola chiave PIVOT è consentita in una query ricorsiva dell'espressione di tabella comune. La query tuttavia restituisce risultati non corretti quando sono presenti più righe per raggruppamento. |
La parola chiave PIVOT non è consentita in una query ricorsiva dell'espressione di tabella comune (CTE). Viene restituito un errore. |
| L'algoritmo RC4 è supportato solo per motivi di compatibilità con le versioni precedenti. È possibile crittografare il nuovo materiale usando RC4 o RC4_128 solo quando il livello di compatibilità del database è 90 o 100. (Non consigliato.) In SQL Server 2012 (11.x) il materiale crittografato usando RC4 o RC4_128 può essere decrittografato in qualsiasi livello di compatibilità. | Il nuovo materiale non può essere crittografato usando RC4 o RC4_128. Usare un algoritmo più recente, ad esempio uno degli algoritmi AES. In SQL Server 2012 (11.x) il materiale crittografato usando RC4 o RC4_128 può essere decrittografato in qualsiasi livello di compatibilità. |
Lo stile predefinito per le operazioni CAST e CONVERT sui tipi di dati time e datetime2 è 121, tranne quando uno dei due tipi viene usato in un'espressione della colonna calcolata. Per le colonne calcolate, lo stile predefinito è 0. Questo comportamento influisce sulle colonne calcolate quando vengono create o usate nelle query con parametrizzazione automatica o nelle definizioni dei vincoli.Esempio D nella sezione Esempi mostra la differenza tra gli stili 0 e 121. Non dimostra il comportamento descritto in precedenza. Per altre informazioni sugli stili di data e ora , vedere CAST e CONVERT. |
Con il livello di compatibilità 110, lo stile predefinito per CAST e CONVERT sui tipi di dati time e datetime2 è sempre 121. Se la query si basa sul comportamento obsoleto, usare un livello di compatibilità inferiore a 110 oppure specificare in modo esplicito lo stile 0 nella query interessata.L'aggiornamento del database al livello di compatibilità 110 non comporta la modifica dei dati utente archiviati su disco. È necessario correggere manualmente questi dati nel modo opportuno. Se ad esempio si usa SELECT INTO per creare una tabella da un'origine che contiene un'espressione della colonna calcolata descritta in precedenza, verranno archiviati i dati (con stile 0), anziché la definizione della colonna calcolata. Sarà necessario aggiornare manualmente questi dati in base allo stile 121. |
| L'operatore + (Addizione) può essere applicato a un operando di tipo date, time, datetime2 o datetimeoffset se l'altro operando ha tipo datetime o smalldatetime. | Il tentativo di applicare l'operatore addizione a un operando di tipo date, time, datetime2 o datetimeoffset e un operando di tipo datetime o smalldatetime genererà l'errore 402. |
| Per tutte le colonne delle tabelle remote di tipo smalldatetime a cui viene fatto riferimento in una vista partizionata viene eseguito il mapping come datetime. Le colonne corrispondenti delle tabelle locali, ovvero le colonne che occupano la stessa posizione ordinale nell'elenco di selezione, devono essere di tipo datetime. | Per tutte le colonne delle tabelle remote di tipo smalldatetime a cui viene fatto riferimento in una vista partizionata viene eseguito il mapping come smalldatetime. Le colonne corrispondenti delle tabelle locali, ovvero le colonne che occupano la stessa posizione ordinale nell'elenco di selezione, devono essere di tipo smalldatetime. Dopo aver effettuato l'aggiornamento al livello di compatibilità 110, la vista partizionata distribuita avrà esito negativo poiché i tipi di dati non corrisponderanno. È possibile risolvere questo problema impostando il tipo di dati nella tabella remota su datetime o impostando il livello di compatibilità del database locale su 100 o su un valore inferiore. |
Tramite la funzione SOUNDEX vengono implementate le regole seguenti:1) Il valore H maiuscolo o W maiuscolo viene ignorato quando si separano due consonanti con lo stesso numero nel SOUNDEX codice.2) Se i primi due caratteri di character_expression hanno lo stesso numero nel SOUNDEX codice, vengono inclusi entrambi i caratteri. Altrimenti, se il numero di un set di consonanti affiancate è uguale nel codice SOUNDEX, vengono escluse tutte le consonanti eccetto la prima. |
Tramite la funzione SOUNDEX vengono implementate le regole seguenti:1) Se la H o W maiuscola separa due consonanti aventi lo stesso numero nel codice SOUNDEX, la consonante a destra viene ignorata2) Se il numero di un set di consonanti affiancate è uguale nel codice SOUNDEX, vengono escluse tutte le consonanti eccetto la prima.Le regole aggiuntive potrebbero causare la differenza dei valori calcolati dalla SOUNDEX funzione rispetto ai valori calcolati con i livelli di compatibilità precedenti. Dopo l'aggiornamento al livello di compatibilità 110, potrebbe essere necessario ricompilare gli indici, gli heap o i vincoli CHECK che usano la SOUNDEX funzione . Per altre informazioni, vedere SOUNDEX. |
L'istruzione STRING_AGG è disponibile senza una clausola <order_clause>. |
L'istruzione STRING_AGG è disponibile con una clausola <order_clause> facoltativa. Per altre informazioni, vedere STRING_AGG |
Differenze tra i livelli di compatibilità 90 e 100
In questa sezione vengono descritti i nuovi comportamenti introdotti con il livello di compatibilità 100.
| Livello di compatibilità 90 | Livello di compatibilità 100 | Probabilità di impatto |
|---|---|---|
| L'impostazione QUOTED_IDENTIFIER è sempre impostata su ON per le funzioni con valori di tabella multistatement quando vengono create indipendentemente dall'impostazione del livello di sessione. | L'impostazione della sessione QUOTED IDENTIFIER viene applicata quando vengono create funzioni con valori di tabella composte da più istruzioni. | Medio |
| Quando si crea o si modifica una funzione di partizione, i valori letterali datetime e smalldatetime nella funzione vengono valutati presupponendo che l'impostazione della lingua sia US_English. | L'impostazione della lingua corrente viene usata per valutare i valori letterali datetime e smalldatetime nella funzione di partizione. | Medio |
La clausola FOR BROWSE è consentita (e ignorata) nelle istruzioni INSERT e SELECT INTO. |
La clausola FOR BROWSE non è consentita nelle istruzioni INSERT e SELECT INTO. |
Medio |
Nella clausola OUTPUT sono consentiti predicati full-text. |
Nella clausola OUTPUT non sono consentiti predicati full-text. |
Basso |
CREATE FULLTEXT STOPLIST, ALTER FULLTEXT STOPLIST e DROP FULLTEXT STOPLIST non sono supportate. Per impostazione predefinita, ai nuovi indici full-text viene associato automaticamente l'elenco di parole non significative di sistema. |
Le istruzioni CREATE FULLTEXT STOPLIST, ALTER FULLTEXT STOPLIST e DROP FULLTEXT STOPLIST sono supportate. |
Basso |
L'istruzione MERGE non viene imposta come parola chiave riservata. |
MERGE è una parola chiave completamente riservata. L'istruzione MERGE è supportata con i livelli di compatibilità 100 e 90. |
Basso |
| Se si usa l'argomento <dml_table_source> dell'istruzione INSERT, viene generato un errore di sintassi. | È possibile acquisire i risultati di una clausola OUTPUT in un'istruzione INSERT, UPDATE, DELETE o MERGE nidificata e inserire tali risultati in una vista o tabella di destinazione. A tale scopo, usare l'argomento <dml_table_source> dell'istruzione INSERT. | Basso |
A meno che non sia specificato NOINDEX, DBCC CHECKDB o DBCC CHECKTABLE esegue controlli di consistenza sia fisica sia logica in una singola tabella o vista indicizzata e in tutti i relativi indici non cluster e XML. Gli indici spaziali non sono supportati. |
A meno che non sia specificato NOINDEX, DBCC CHECKDB o DBCC CHECKTABLE esegue controlli di consistenza sia fisica sia logica in una singola tabella e in tutti i relativi indici non cluster. Per impostazione predefinita, tuttavia, negli indici XML, negli indici spaziali e nelle viste indicizzate vengono eseguiti solo controlli di consistenza fisica.Se è specificato WITH EXTENDED_LOGICAL_CHECKS, vengono eseguiti controlli logici su viste indicizzate, indici XML e indici spaziali, laddove presenti. Per impostazione predefinita, i controlli di consistenza fisica vengono eseguiti prima di quelli di consistenza logica. Se viene specificato anche NOINDEX, vengono eseguiti solo i controlli logici. |
Basso |
| Quando una clausola OUTPUT viene utilizzata con un'istruzione DML (Data Manipulation Language) e si verifica un errore di run-time durante l'esecuzione di istruzioni, l'intera transazione viene terminata e ne viene eseguito il rollback. | Quando una clausola OUTPUT viene usata con un'istruzione DML (Data Manipulation Language) e si verifica un errore di runtime durante l'esecuzione delle istruzioni, il comportamento dipende dall'impostazione di SET XACT_ABORT. Se SET XACT_ABORT è OFF, un errore di interruzione dell'istruzione generato dall'istruzione DML che usa la OUTPUT clausola terminerà l'istruzione, ma l'esecuzione del batch continua e la transazione non viene eseguito il rollback. Se SET XACT_ABORT è impostato su ON, tutti gli errori di runtime generati dall'istruzione DML tramite la clausola OUTPUT termineranno il batch e verrà eseguito il rollback della transazione. |
Basso |
| CUBE e ROLLUP non vengono applicati come parole chiave riservate. | CUBE e ROLLUP sono parole chiave riservate all'interno della clausola GROUP BY. |
Basso |
| Agli elementi del tipo anyType XML viene applicata una convalida di tipo strict. | Agli elementi del tipo anyType viene applicata una convalida di tipo lax. Per altre informazioni, vedere Componenti jolly e convalida del contenuto. | Basso |
| Gli attributi speciali xsi:nil e xsi:type non possono essere sottoposti a query o modificati dalle istruzioni del linguaggio di manipolazione dei dati. Di conseguenza, /e/@xsi:nil ha esito negativo, mentre /e/@* ignora gli attributi xsi:nil e xsi:type. /e restituisce tuttavia gli attributi xsi:nil e xsi:type per la consistenza con SELECT xmlCol, anche se xsi:nil = "false". |
Gli attributi speciali xsi:nil e xsi:type vengono archiviati come attributi regolari e possono essere sottoposti a query o modificati. L'esecuzione della query SELECT x.query('a/b/@*') restituisce ad esempio tutti gli attributi, inclusi xsi:nil e xsi:type. Per escludere questi tipi nella query, sostituire @* con @*[namespace-uri(.) != "insert xsi namespace uri" e non (local-name(.) = "type" o local-name(.) ="nil". |
Basso |
| Una funzione definita dall'utente che converte un valore stringa costante XML in un tipo datetime di SQL Server viene contrassegnata come deterministica. | Una funzione definita dall'utente che converte un valore stringa costante XML in un tipo datetime di SQL Server viene contrassegnata come non deterministica. | Basso |
| I tipi unione ed elenco XML non sono supportati completamente. | I tipi unione ed elenco sono supportati completamente, incluse le funzionalità seguenti. Unione di elenco Unione di unione Elenco di tipi atomici Elenco di unione |
Basso |
| Le opzioni SET necessarie per un metodo xQuery non vengono convalidate quando il metodo è contenuto in una vista o in una funzione con valori di tabella inline. | Le opzioni SET necessarie per un metodo xQuery vengono convalidate quando il metodo è contenuto in una vista o in una funzione inline con valori di tabella. Se le opzioni SET del metodo non sono impostate correttamente, viene generato un errore. | Basso |
| I valori di attributo XML contenenti caratteri di fine riga (ritorno a capo e avanzamento riga) non vengono normalizzati in base allo standard XML, ovvero vengono restituiti entrambi i caratteri anziché un singolo carattere di avanzamento riga. | I valori di attributo XML contenenti caratteri di fine riga (ritorno a capo e avanzamento riga) vengono normalizzati in base allo standard XML, Ovvero, tutte le interruzioni di riga nelle entità analizzate esterne (inclusa l'entità documento) vengono normalizzate in base all'input convertendo sia la sequenza a due caratteri #xD #xA che qualsiasi #xD che non è seguita da #xA a un singolo carattere #xA. Le applicazioni che usano attributi per il trasporto di valori stringa che contengono caratteri di fine riga non riceveranno questi caratteri quando vengono inviati. Per evitare il processo di normalizzazione, utilizzare entità di caratteri numerici XML per codificare tutti i caratteri di fine riga. |
Basso |
Le proprietà di colonna ROWGUIDCOL e IDENTITY possono essere erroneamente denominate come vincolo. L'istruzione CREATE TABLE T (C1 int CONSTRAINT MyConstraint IDENTITY), ad esempio, viene eseguita correttamente, ma il nome del vincolo non viene mantenuto e non è accessibile per l'utente. |
Le proprietà di colonna ROWGUIDCOL e IDENTITY non possono essere denominate come vincolo. In caso contrario, verrà restituito l'errore 156. |
Basso |
L'aggiornamento di colonne con un'assegnazione bidirezionale, ad esempio UPDATE T1 SET @v = column_name = <expression>, può produrre risultati imprevisti, poiché è possibile che durante l'esecuzione dell'istruzione in altre clausole, ad esempio WHERE e ON, venga usato il valore attivo della variabile anziché il valore iniziale dell'istruzione. Ciò può comportare una modifica imprevista dei significati dei predicati per ciascuna riga.Questo comportamento è applicabile solo quando il livello di compatibilità è impostato su 90. |
L'aggiornamento di colonne tramite un'assegnazione bidirezionale produce i risultati previsti, in quanto durante l'esecuzione dell'istruzione è possibile accedere solo al valore iniziale dell'istruzione per la colonna. | Basso |
L'assegnazione di variabili è consentita in un'istruzione contenente un operatore di primo livello UNION , ma restituisce risultati imprevisti. Per altre informazioni, vedere l'esempio E. |
L'assegnazione di variabili non è consentita in un'istruzione contenente un operatore UNION di primo livello. In caso contrario, verrà restituito l'errore 10734. Cercare una riscrittura suggerita nell'esempio E. | Basso |
La funzione ODBC {fn CONVERT()} utilizza il formato di data predefinito della lingua specifica. Per alcune lingue il formato predefinito è AGM, che può comportare errori di conversione quando la funzione CONVERT() è combinata con altre funzioni, ad esempio {fn CURDATE()}, che prevedono l'uso del formato AMG. |
La funzione ODBC {fn CONVERT()} usa lo stile 121, un formato AMG indipendente dalla lingua, per la conversione nei tipi di dati ODBC SQL_TIMESTAMP, SQL_DATE, SQL_TIME, SQLDATE, SQL_TYPE_TIME e SQL_TYPE_TIMESTAMP. |
Basso |
Gli intrinseci Datetime, DATEPART ad esempio, non richiedono valori di input stringa come valori letterali datetime validi. Ad esempio, SELECT DATEPART (year, '2007/05-30') viene compilato correttamente. |
Le funzioni intrinseche datetime, ad esempio DATEPART, richiedono che i valori di input di tipo stringa siano valori letterali datetime validi. Quando si utilizza un valore letterale datetime non valido, viene restituito l'errore 241. |
Basso |
Gli spazi finali specificati nel primo parametro di input per la funzione REPLACE vengono eliminati quando il parametro è di tipo char. Nell'istruzione SELECT '<' + REPLACE(CONVERT(char(6), 'ABC '), ' ', 'L') + '>', ad esempio, il valore 'ABC ' viene erroneamente valutato come 'ABC'. |
Gli spazi finali vengono sempre mantenuti. Per le applicazioni che si basano sul comportamento precedente della funzione, usare la RTRIM funzione quando si specifica il primo parametro di input per la funzione. Ad esempio, la sintassi seguente riproduce il comportamento di SQL Server 2005: SELECT '<' + REPLACE(RTRIM(CONVERT(char(6), 'ABC ')), ' ', 'L') + '>'. |
Basso |
Parole chiave riservate
L'impostazione di compatibilità determina anche le parole chiave riservate dal motore di database. Nella tabella seguente sono elencate le parole chiave riservate introdotte per ogni livello di compatibilità.
| Livello di compatibilità | Parole chiave riservate |
|---|---|
| 130 | Da determinare. |
| 120 | Nessuno. |
| 110 | WITHIN GROUP, TRY_CONVERT, SEMANTICKEYPHRASETABLE, SEMANTICSIMILARITYDETAILSTABLESEMANTICSIMILARITYTABLE |
| 100 | CUBE, MERGE, ROLLUP |
| 90 | EXTERNAL, PIVOT, UNPIVOT, REVERTTABLESAMPLE |
A un determinato livello di compatibilità, le parole chiave riservate includono tutte le parole chiave introdotte per tale livello e per quelli precedenti. Pertanto, ad esempio, per le applicazioni con livello 110 tutte le parole chiave elencate nella tabella precedente sono parole chiave riservate. Per i livelli di compatibilità inferiori, le parole chiave del livello 100 rimangono nomi di oggetti validi ma le funzionalità del linguaggio di livello 110 corrispondenti a tale parole chiave non sono disponibili.
Una volta introdotta, una parola chiave rimane riservata. La parola chiave riservata PIVOT, ad esempio, introdotta per il livello di compatibilità 90, è riservata per i livelli 100, 110 e 120.
Se per un'applicazione si utilizza un identificatore che rappresenta una parola chiave riservata nel livello di compatibilità relativo, viene generato un errore. In alternativa, racchiudere l'identificatore tra parentesi quadre ([]) o virgolette (""). Per aggiornare ad esempio un'applicazione che usa l'identificatore EXTERNAL al livello di compatibilità 90, è possibile modificare l'identificatore in [EXTERNAL] o "EXTERNAL".
Per altre informazioni, vedere Parole chiave riservate.
Autorizzazioni
È richiesta l'autorizzazione ALTER per il database.
Esempi
R. Modificare il livello di compatibilità
Nell'esempio seguente viene modificato il livello di compatibilità del AdventureWorks2022database di esempio su 150, il valore predefinito per SQL Server 2019 (15.x).
ALTER DATABASE AdventureWorks2022
SET COMPATIBILITY_LEVEL = 150;
GO
Nell'esempio seguente viene restituito il livello di compatibilità del database corrente.
SELECT name, compatibility_level
FROM sys.databases
WHERE name = db_name();
GO
B. L'istruzione SET LANGUAGE viene ignorata tranne che nel livello di compatibilità 120 o successivo
La query seguente ignora l'istruzione SET LANGUAGE tranne che nel livello di compatibilità 120 o superiore.
SET DATEFORMAT dmy;
DECLARE @t2 date = '12/5/2011' ;
SET LANGUAGE dutch;
SELECT CONVERT(varchar(11), @t2, 106);
GO
Risultati quando il livello di compatibilità è minore di 120: 12 May 2011
Risultati quando il livello di compatibilità è impostato su 120 o superiore: 12 mei 2011
C. Per il livello di compatibilità impostato su 110 o un valore inferiore, i riferimenti ricorsivi a destra di una clausola EXCEPT creano un ciclo infinito
WITH cte AS
(SELECT * FROM (VALUES (1),(2),(3)) v (a)),
r AS
(SELECT a FROM cte
UNION ALL
(SELECT a FROM cte EXCEPT SELECT a FROM r)
)
SELECT a
FROM r;
GO
D. La differenza tra gli stili 0 e 121
Quando il livello di compatibilità è inferiore a 110, lo stile predefinito per le operazioni CAST e CONVERT sui tipi di dati time e datetime2 è 121, tranne quando uno dei due tipi viene usato in un'espressione di colonna calcolata. Per le colonne calcolate, lo stile predefinito è 0.
Quando il livello di compatibilità 110 o superiore, lo stile predefinito per le operazioni CAST e CONVERT sui tipi di dati time e datetime2 è sempre 121. Per altre informazioni, vedere Differenze tra i livelli di compatibilità inferiori e i livelli 100 e 110.
Per altre informazioni sugli stili di data e ora, vedere CAST e CONVERT.
DROP TABLE IF EXISTS t1;
GO
CREATE TABLE t1 (c1 time(7), c2 datetime2);
GO
INSERT t1 (c1,c2) VALUES (GETDATE(), GETDATE());
GO
SELECT CONVERT(nvarchar(16),c1,0) AS TimeStyle0
,CONVERT(nvarchar(16),c1,121)AS TimeStyle121
,CONVERT(nvarchar(32),c2,0) AS Datetime2Style0
,CONVERT(nvarchar(32),c2,121)AS Datetime2Style121
FROM t1;
GO
I risultati restituiti sono simili ai seguenti:
| TimeStyle0 | TimeStyle121 | Datetime2Style0 | Datetime2Style121 |
|---|---|---|---|
| 3:15PM | 15:15:35.8100000 | Jun 7 2011 3:15PM | 2011-06-07 15:15:35.8130000 |
E. Assegnazione di variabile - Operatore UNION di livello principale
Nell'impostazione del livello di compatibilità del database 90, l'assegnazione di variabili è consentita in un'istruzione contenente un operatore UNION di primo livello, ma restituisce risultati imprevisti. Nelle istruzioni seguenti, ad esempio, alla variabile locale @v è assegnato il valore della colonna BusinessEntityID dall'unione di due tabelle. Per definizione, quando l'istruzione SELECT restituisce più valori, alla variabile viene assegnato l'ultimo valore restituito. In questo caso, alla variabile viene assegnato correttamente l'ultimo valore, ma viene restituito anche il set di risultati dell'istruzione SELECT UNION.
ALTER DATABASE AdventureWorks2022
SET compatibility_level = 110;
GO
USE AdventureWorks2022;
GO
DECLARE @v int;
SELECT @v = BusinessEntityID FROM HumanResources.Employee
UNION ALL
SELECT @v = BusinessEntityID FROM HumanResources.EmployeeAddress;
SELECT @v;
Nell'impostazione del livello di compatibilità del database 100 e versioni successive, l'assegnazione di variabili non è consentita in un'istruzione contenente un operatore UNION di primo livello. In caso contrario, verrà restituito l'errore 10734.
Per risolvere questo errore, riscrivere la query come illustrato nell'esempio seguente.
DECLARE @v int;
SELECT @v = BusinessEntityID FROM
(SELECT BusinessEntityID FROM HumanResources.Employee
UNION ALL
SELECT BusinessEntityID FROM HumanResources.EmployeeAddress) AS Test;
SELECT @v;
Contenuto correlato
- Mantenere la stabilità delle prestazioni durante l'aggiornamento a SQL Server più recente
- Modificare il livello di compatibilità del database e usare Query Store
- Certificazione di compatibilità
- ALTER DATABASE (Transact-SQL)
- Aggiornare i database tramite l’Assistente ottimizzazione query
- CREATE DATABASE
- Visualizzare o modificare il livello di compatibilità di un database
- Hint di Query Store
Commenti e suggerimenti
Presto disponibile: nel corso del 2024 verranno dismessi i problemi di GitHub come meccanismo di feedback per il contenuto e verranno sostituiti con un nuovo sistema di feedback. Per altre informazioni, vedere: https://aka.ms/ContentUserFeedback.
Invia e visualizza il feedback per