Notitie
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen u aan te melden of de directory te wijzigen.
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen de mappen te wijzigen.
Van toepassing op:SQL Server
Azure SQL Database
Azure SQL Managed Instance
Hiermee stelt u Transact-SQL- en queryverwerkingsgedrag in om compatibel te zijn met de opgegeven versie van de SQL-engine. Zie ALTER DATABASEvoor andere opties voor ALTER DATABASE.
Zie Transact-SQL syntaxisconventiesvoor meer informatie over de syntaxisconventies.
Syntaxis
ALTER DATABASE database_name
SET COMPATIBILITY_LEVEL = { 170 | 160 | 150 | 140 | 130 | 120 | 110 | 100 }
Argumenten
database_name
De naam van de database die moet worden gewijzigd.
COMPATIBILITY_LEVEL { 170 | 160 | 150 | 140 | 130 | 120 | 110 | 100 | 90 | 80 }
De versie van SQL Server waarmee de database compatibel moet worden gemaakt. De volgende compatibiliteitsniveauwaarden kunnen worden geconfigureerd (niet alle versies ondersteunen alle bovenstaande compatibiliteitsniveaus):
Product | Database Engine-versie | Standaardinstelling voor compatibiliteitsniveau | Ondersteunde compatibiliteitsniveauwaarden |
---|---|---|---|
Azure SQL Database | zeventien | 170 | 170, 160, 150, 140, 130, 120, 110, 100 |
Azure SQL Managed Instance (een beheerde database-instantie van Azure) | 16 | 150 | 160, 150, 140, 130, 120, 110, 100 |
SQL Server 2025 (17.x) Preview | zeventien | 170 | 170, 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 |
Belangrijk
De versienummers van de database-engine voor SQL Server en Azure SQL Database zijn niet vergelijkbaar met elkaar en zijn in plaats daarvan interne buildnummers voor deze afzonderlijke producten. De database-engine voor Azure SQL Database is gebaseerd op dezelfde codebasis als de SQL Server-database-engine. Het belangrijkste is dat de database-engine in Azure SQL Database altijd beschikt over de nieuwste BITS van de SQL-database-engine. Versie 12 van Azure SQL Database is nieuwer dan versie 15 van SQL Server.
Aanbevolen procedures voor het upgraden van databasecompatibiliteitsniveau
Zie Prestatiestabiliteit behouden tijdens de upgrade naar nieuwere SQL Server voor de aanbevolen werkstroom voor het upgraden van het compatibiliteitsniveau. Voor een ondersteunde ervaring met het upgraden van het databasecompatibiliteitsniveau raadpleegt u Bovendien Upgradedatabases met behulp van de Query Tuning Assistant.
Opmerkingen
Voor alle installaties van SQL Server is het standaardcompatibiliteitsniveau gekoppeld aan de versie van de database-engine. Nieuwe databases zijn ingesteld op dit niveau, tenzij de model
database een lager compatibiliteitsniveau heeft. Voor databases die zijn gekoppeld aan of hersteld vanuit een eerdere versie van SQL Server, behoudt de database het bestaande compatibiliteitsniveau als deze ten minste is toegestaan voor dat exemplaar van SQL Server. Als u een database verplaatst met een compatibiliteitsniveau dat lager is dan het toegestane niveau door de Database Engine, wordt de database automatisch ingesteld op het laagste compatibiliteitsniveau dat is toegestaan. Dit geldt zowel voor systeem- als gebruikersdatabases.
Het volgende gedrag wordt verwacht voor SQL Server 2017 (14.x) wanneer een database is gekoppeld of hersteld en na een in-place upgrade:
- Als het compatibiliteitsniveau van een gebruikersdatabase vóór de upgrade 100 of hoger was, blijft deze na de upgrade hetzelfde.
- Als het compatibiliteitsniveau van een gebruikersdatabase 90 was vóór de upgrade, wordt in de bijgewerkte database het compatibiliteitsniveau ingesteld op 100. Dit is het laagste ondersteunde compatibiliteitsniveau in SQL Server 2017 (14.x).
- De compatibiliteitsniveaus van de
tempdb
databases ,model
enmsdb
resourcedatabases zijn ingesteld op het standaardcompatibiliteitsniveau voor een bepaalde database-engineversie. - De
master
systeemdatabase behoudt het compatibiliteitsniveau dat deze vóór de upgrade had. Dit heeft geen invloed op het gedrag van de gebruikersdatabase.
Voor bestaande databases die worden uitgevoerd op lagere compatibiliteitsniveaus, zolang de toepassing geen verbeteringen hoeft te gebruiken die alleen beschikbaar zijn in een hoger databasecompatibiliteitsniveau, is het een geldige benadering om het vorige compatibiliteitsniveau van de database te behouden. Voor nieuwe ontwikkelwerkzaamheden of wanneer voor een bestaande toepassing nieuwe functies nodig zijn, zoals Intelligente queryverwerking in SQL-databases en een aantal nieuwe Transact-SQL-databases, moet u het compatibiliteitsniveau van de database upgraden naar het meest recente beschikbare niveau. Zie Compatibiliteitsniveaus en Database Engine-upgrades voor meer informatie.
Opmerking
Als er geen gebruikersobjecten en afhankelijkheden zijn, is het over het algemeen veilig om een upgrade uit te voeren naar het standaardcompatibiliteitsniveau. Zie Aanbevelingen - hoofddatabase voor meer informatie.
Hiermee ALTER DATABASE
wijzigt u het compatibiliteitsniveau van de database. De instelling voor het nieuwe compatibiliteitsniveau voor een database wordt van kracht wanneer een USE <database>
opdracht wordt uitgegeven, of er wordt een nieuwe aanmelding verwerkt met die database als standaarddatabasecontext.
Als u het huidige compatibiliteitsniveau van een database wilt weergeven, voert u een query uit op de compatibility_level
kolom in de catalogusweergave sys.databases .
Een distributiedatabase die is gemaakt in een eerdere versie van SQL Server en wordt bijgewerkt naar SQL Server 2016 (13.x) RTM of Service Pack 1 heeft een compatibiliteitsniveau van 90, dat niet wordt ondersteund voor andere databases. Dit heeft geen invloed op de functionaliteit van replicatie. Als u een upgrade uitvoert naar latere servicepacks en versies van SQL Server, wordt het compatibiliteitsniveau van de distributiedatabase verhoogd zodat deze overeenkomt met die van de master
database.
Als u databasecompatibiliteitsniveau 120 of hoger wilt gebruiken voor een database in het algemeen, maar opt-in voor het kardinaliteitschattingsmodel van SQL Server 2012 (11.x), dat is toegewezen aan databasecompatibiliteitsniveau 110, raadpleegt u ALTER DATABASE SCOPED CONFIGURATION, en met name het trefwoord LEGACY_CARDINALITY_ESTIMATION = ON
.
Opmerkingen voor Azure SQL
Het standaardcompatibiliteitsniveau is 170 voor nieuw gemaakte databases in Azure SQL Database en SQL Database in Microsoft Fabric.
Het standaardcompatibiliteitsniveau is 150 voor nieuw gemaakte databases in het updatebeleid van SQL Server 2022 van het azure SQL Managed Instance-aanbod.
Het standaardcompatibiliteitsniveau is 170 voor nieuwe databases in het always-up-to-datum-updatebeleid van het azure SQL Managed Instance-aanbod.
Microsoft werkt het compatibiliteitsniveau van de database niet automatisch bij voor bestaande databases. Het is aan klanten om naar eigen goeddunken te doen.
Microsoft raadt klanten ten zeerste aan om te upgraden naar het meest recente compatibiliteitsniveau om de meest recente optimalisatieverbeteringen voor query's te kunnen gebruiken. Zie Verbeterde queryprestaties met compatibiliteitsniveau 130 in Azure SQL Database voor tips over het beoordelen van de prestatieverschillen van uw belangrijkste query's tussen twee verschillende compatibiliteitsniveaus in Azure SQL Database. Dit artikel verwijst naar compatibiliteitsniveau 130 en SQL Server, maar dezelfde methodologie geldt voor upgrades naar 140 of hoger niveaus in SQL Server en Azure SQL Database.
Niet alle functies die per compatibiliteitsniveau variëren, worden ondersteund in Azure SQL Database.
Huidig compatibiliteitsniveau zoeken
Als u het huidige compatibiliteitsniveau wilt bepalen, voert u een query uit op de compatibility_level
kolom sys.databases.
SELECT [name],
compatibility_level
FROM sys.databases;
Voer de volgende query uit om te bepalen met welke versie van de database-engine u verbinding hebt.
SELECT SERVERPROPERTY('ProductVersion');
Compatibiliteitsniveaus en upgrades van database-engine
Databasecompatibiliteitsniveau is een waardevol hulpmiddel om te helpen bij het moderniseren van databases door de SQL Server Database Engine te laten upgraden en tegelijkertijd dezelfde functionele status te behouden voor het verbinden van toepassingen door hetzelfde compatibiliteitsniveau voor de database vóór de upgrade te behouden. Dit betekent dat het mogelijk is om een upgrade uit te voeren van een oudere versie van SQL Server (zoals SQL Server 2008 (10.0.x)) naar SQL Server of Azure SQL Database (inclusief Azure SQL Managed Instance) zonder toepassingswijzigingen (met uitzondering van databaseconnectiviteit). Zie Compatibiliteitscertificering voor meer informatie.
Zolang de toepassing geen verbeteringen hoeft te gebruiken die alleen beschikbaar zijn in een hoger databasecompatibiliteitsniveau, is het een geldige methode om de SQL Server Database Engine bij te werken en het vorige compatibiliteitsniveau van de database te behouden. Zie Compatibiliteitscertificering voor meer informatie over het gebruik van compatibiliteitsniveau voor achterwaartse compatibiliteit.
Compatibiliteitsniveaus en opgeslagen procedures
Wanneer een opgeslagen procedure wordt uitgevoerd, wordt het huidige compatibiliteitsniveau van de database gebruikt waarin deze is gedefinieerd. Wanneer de compatibiliteitsinstelling van een database wordt gewijzigd, worden alle opgeslagen procedures automatisch opnieuw gecompileerd.
Compatibiliteitsniveau gebruiken voor compatibiliteit met eerdere versies
De instelling voor databasecompatibiliteitsniveau biedt compatibiliteit met eerdere versies van SQL Server in verband met Transact-SQL en queryoptimalisatiegedrag alleen voor de opgegeven database, niet voor de hele server.
Vanaf de compatibiliteitsmodus 130 zijn alle nieuwe queryplannen die van invloed zijn op fixes en functies opzettelijk toegevoegd aan het nieuwe compatibiliteitsniveau. Dit is gedaan om het risico te minimaliseren tijdens upgrades die voortvloeien uit prestatievermindering als gevolg van wijzigingen in het queryplan die mogelijk worden geïntroduceerd door nieuw gedrag voor queryoptimalisatie.
Gebruik vanuit het perspectief van een toepassing het lagere compatibiliteitsniveau als een veiliger migratiepad om versieverschillen te omzeilen, in het gedrag dat wordt beheerd door de relevante instelling voor compatibiliteitsniveau. Het doel moet nog steeds zijn om op een bepaald moment een upgrade uit te voeren naar het nieuwste compatibiliteitsniveau, om enkele van de nieuwe functies, zoals intelligente queryverwerking in SQL-databases, over te nemen, maar om dit op een gecontroleerde manier te doen.
Stopgezette functionaliteit die is geïntroduceerd in een bepaalde SQL Server-versie, wordt niet beveiligd door compatibiliteitsniveau. Dit verwijst naar functionaliteit die is verwijderd uit de SQL Server Database Engine. De hint is bijvoorbeeld
FASTFIRSTROW
stopgezet in SQL Server 2012 (11.x) en vervangen door deOPTION (FAST n )
hint. Als u het compatibiliteitsniveau van de database instelt op 110, wordt de stopgezette hint niet hersteld. Zie Stopgezette database-enginefunctionaliteit in SQL Server voor meer informatie over stopgezette functionaliteit.Belangrijke wijzigingen die zijn geïntroduceerd in een bepaalde SQL Server-versie, worden mogelijk niet beveiligd met compatibiliteitsniveau. Dit verwijst naar gedragswijzigingen tussen versies van de SQL Server Database Engine. Transact-SQL gedrag wordt meestal beschermd door compatibiliteitsniveau. Gewijzigde of verwijderde systeemobjecten worden echter niet beveiligd door compatibiliteitsniveau.
Een voorbeeld van een wijziging die fouten veroorzaakt die door compatibiliteitsniveau wordt beveiligd , is een impliciete conversie van datum/tijd tot datum/tijd2-gegevenstypen . Onder databasecompatibiliteitsniveau 130 tonen deze verbeterde nauwkeurigheid door rekening te maken met de fractionele milliseconden, wat resulteert in verschillende geconverteerde waarden. Als u het vorige conversiegedrag wilt herstellen, stelt u het compatibiliteitsniveau van de database in op 120 of lager.
Voorbeelden van wijzigingen die fouten veroorzaken die niet door compatibiliteitsniveau worden beveiligd, zijn:
Kolomnamen in systeemobjecten gewijzigd. In SQL Server 2012 (11.x) is de naam van de kolom
single_pages_kb
gewijzigd insys.dm_os_sys_info
.pages_kb
Ongeacht het compatibiliteitsniveau produceert de querySELECT single_pages_kb FROM sys.dm_os_sys_info
fout 207 (ongeldige kolomnaam).Systeemobjecten verwijderd. In SQL Server 2012 (11.x) is het
sp_dboption
verwijderd. Ongeacht het compatibiliteitsniveau produceert de instructieEXEC sp_dboption 'AdventureWorks2022', 'autoshrink', 'FALSE';
fout 2812 (Could not find stored procedure 'sp_dboption'
).Zie voor meer informatie over wijzigingen die fouten veroorzaken:
Verschillen tussen compatibiliteitsniveaus
Voor alle installaties van SQL Server is het standaardcompatibiliteitsniveau gekoppeld aan de versie van de database-engine, zoals te zien is in deze tabel. Voor nieuwe ontwikkelwerkzaamheden moet u altijd toepassingen certificeren op het meest recente compatibiliteitsniveau van de database.
Nieuwe Transact-SQL syntaxis wordt niet door databasecompatibiliteitsniveau beveiligd, behalve wanneer bestaande toepassingen kunnen worden verbroken door een conflict met Transact-SQL code van de gebruiker te maken. Deze uitzonderingen worden beschreven in de volgende secties van dit artikel waarin de verschillen tussen specifieke compatibiliteitsniveaus worden beschreven.
Databasecompatibiliteitsniveau biedt ook achterwaartse compatibiliteit met eerdere versies van SQL Server, omdat databases die zijn gekoppeld aan of hersteld vanuit een eerdere versie van SQL Server, hun bestaande compatibiliteitsniveau behouden (indien hetzelfde of hoger dan het minimaal toegestane compatibiliteitsniveau). Dit is besproken in het gedeelte Compatibiliteitsniveau Gebruiken voor achterwaartse compatibiliteit van dit artikel.
Vanaf databasecompatibiliteitsniveau 130 zijn eventuele nieuwe oplossingen en functies die van invloed zijn op queryplannen alleen toegevoegd aan het meest recente compatibiliteitsniveau dat beschikbaar is, ook wel het standaardcompatibiliteitsniveau genoemd. Dit is gedaan om het risico te minimaliseren tijdens upgrades die voortvloeien uit prestatievermindering als gevolg van wijzigingen in het queryplan, mogelijk geïntroduceerd door nieuw gedrag voor queryoptimalisatie.
De fundamentele wijzigingen die van invloed zijn op het plan, worden alleen toegevoegd aan het standaardcompatibiliteitsniveau van een nieuwe versie van de database-engine:
Query Optimizer-oplossingen die zijn uitgebracht voor eerdere SQL Server-versies onder traceringsvlag 4199, worden automatisch ingeschakeld in het standaardcompatibiliteitsniveau van een nieuwere SQL Server-versie.
Van toepassing op: SQL Server (vanaf versie SQL Server 2016 (13.x)), Azure SQL Database.
Wanneer SQL Server 2016 (13.x) bijvoorbeeld werd uitgebracht, werden alle fixes van Query Optimizer die zijn uitgebracht voor eerdere SQL Server-versies (en de respectieve compatibiliteitsniveaus 100 tot en met 120) automatisch ingeschakeld voor databases die gebruikmaken van het standaardcompatibiliteitsniveau SQL Server 2016 (13.x). Alleen fixes na RTM Query Optimizer moeten expliciet worden ingeschakeld.
Als u oplossingen voor Query Optimizer wilt inschakelen, kunt u de volgende methoden gebruiken:
- Op serverniveau met traceringsvlag 4199.
- Op databaseniveau met de
QUERY_OPTIMIZER_HOTFIXES
optie ALTER DATABASE SCOPED CONFIGURATION (Transact-SQL). - Op queryniveau, met de
USE HINT 'ENABLE_QUERY_OPTIMIZER_HOTFIXES'
queryhint door de query te wijzigen. - Op queryniveau, met de
USE HINT 'ENABLE_QUERY_OPTIMIZER_HOTFIXES'
functie zonder codewijzigingen, gebruikt u de functie Hints voor Query Store .
Later, toen SQL Server 2017 (14.x) werd uitgebracht, werden alle oplossingen voor Query Optimizer uitgebracht nadat SQL Server 2016 (13.x) RTM automatisch werd ingeschakeld voor databases die gebruikmaken van het standaardcompatibiliteitsniveau SQL Server 2017 (14.x). Dit is een cumulatief gedrag dat ook alle eerdere versiesfixes bevat. Nogmaals, alleen fixes na RTM Query Optimizer moeten expliciet worden ingeschakeld.
De volgende tabel bevat een overzicht van dit gedrag:
Database Engine-versie (DE) Databasecompatibiliteitsniveau TF 4199 QO-wijzigingen ten opzichte van alle vorige databasecompatibiliteitsniveaus QO-wijzigingen voor (DE) versie na RTM 13 (SQL Server 2016 (13.x)) 100 tot 120
130Uit
Op
Uit
OpInvalide
Ingeschakeld
Ingeschakeld
IngeschakeldUitgeschakeld
Ingeschakeld
Uitgeschakeld
Ingeschakeld14 (SQL Server 2017 (14.x)) 100 tot 120
130
140Uit
Op
Uit
Op
Uit
OpInvalide
Ingeschakeld
Ingeschakeld
Ingeschakeld
Ingeschakeld
IngeschakeldUitgeschakeld
Ingeschakeld
Uitgeschakeld
Ingeschakeld
Uitgeschakeld
Ingeschakeld15 (SQL Server 2019 (15.x)) en (Azure SQL Database) 100 tot 120
130 tot 140
150Uit
Op
Uit
Op
Uit
OpInvalide
Ingeschakeld
Ingeschakeld
Ingeschakeld
Ingeschakeld
IngeschakeldUitgeschakeld
Ingeschakeld
Uitgeschakeld
Ingeschakeld
Uitgeschakeld
Ingeschakeld16 (SQL Server 2022 (16.x)) en (Azure SQL Database) 100 tot 120
130 tot 150
160Uit
Op
Uit
Op
Uit
OpInvalide
Ingeschakeld
Ingeschakeld
Ingeschakeld
Ingeschakeld
IngeschakeldUitgeschakeld
Ingeschakeld
Uitgeschakeld
Ingeschakeld
Uitgeschakeld
Ingeschakeld17 (SQL Server 2025 (17.x) Preview, Azure SQL Database en SQL-database in Microsoft Fabric) 100 tot 120
130 tot 160
170Uit
Op
Uit
Op
Uit
OpInvalide
Ingeschakeld
Ingeschakeld
Ingeschakeld
Ingeschakeld
IngeschakeldUitgeschakeld
Ingeschakeld
Uitgeschakeld
Ingeschakeld
Uitgeschakeld
IngeschakeldQuery Optimizer lost onjuiste resultaten op of fouten met toegangsschendingen worden niet beveiligd door traceringsvlag 4199. Deze oplossingen worden niet als optioneel beschouwd.
Wijzigingen in de kardinaliteitsschatter die zijn uitgebracht op SQL Server, Azure SQL Database en SQL-database in Microsoft Fabric, zijn alleen ingeschakeld in het standaardcompatibiliteitsniveau van een nieuwe database-engineversie, maar niet op eerdere compatibiliteitsniveaus.
Wanneer bijvoorbeeld SQL Server 2016 (13.x) werd uitgebracht, waren wijzigingen in het kardinaliteitschattingsproces alleen beschikbaar voor databases die sql Server 2016 (13.x) standaardcompatibiliteitsniveau (130) gebruiken. Eerdere compatibiliteitsniveaus behouden het gedrag van de kardinaliteitschatting die beschikbaar was vóór SQL Server 2016 (13.x).
Later, toen SQL Server 2017 (14.x) werd uitgebracht, waren nieuwere wijzigingen in het kardinaliteitsramingsproces alleen beschikbaar voor databases met sql Server 2017 (14.x) standaardcompatibiliteitsniveau (140). Databasecompatibiliteitsniveau 130 heeft het gedrag van de kardinaliteitschatting van SQL Server 2016 (13.x) behouden.
De volgende tabel bevat een overzicht van dit gedrag:
Database Engine-versie Databasecompatibiliteitsniveau Ce-wijzigingen van nieuwe versie 13 (SQL Server 2016 (13.x)) < 130
130Uitgeschakeld
Ingeschakeld14 (SQL Server 2017 (14.x))1 < 140
140Uitgeschakeld
Ingeschakeld15 (SQL Server 2019 (15.x))1 < 150
150Uitgeschakeld
Ingeschakeld16 (SQL Server 2022 (16.x))1 < 160
160Uitgeschakeld
Ingeschakeld17 (SQL Server 2025 (17.x) Preview)1 < 170
170Uitgeschakeld
Ingeschakeld1 Ook van toepassing op Azure SQL Database en SQL-database in Microsoft Fabric.
Andere verschillen tussen specifieke compatibiliteitsniveaus zijn beschikbaar in de volgende secties van dit artikel.
Verschillen tussen compatibiliteitsniveau 160 en niveau 170
In deze sectie worden nieuwe gedragingen beschreven die zijn geïntroduceerd met compatibiliteitsniveau 170.
Instelling voor compatibiliteitsniveau van 160 of lager | Instelling voor compatibiliteitsniveau van 170 |
---|---|
Om het sleutelmateriaal van de symmetrische sleutel, databasehoofdsleutel en servicehoofdsleutel te beveiligen, slaat SQL Server en Azure SQL het sleutelmateriaal in versleutelde vorm op. De versleuteling maakt gebruik van de PKCS#1 v1.5 opvullingsmodus. | Om het sleutelmateriaal van de symmetrische sleutel, databasehoofdsleutel en servicehoofdsleutel te beveiligen, slaat SQL Server en Azure SQL het sleutelmateriaal in versleutelde vorm op. De versleuteling maakt gebruik van de opvullingsmodus OAEP-256. In de dm_database_encryption_keys wordt de encryptor_type weergegeven als CERTIFICATE_OAEP_256 in plaats van CERTIFICATE . |
Reguliere expressies kunnen worden gebruikt om complexe patronen te vinden en gegevens te bewerken in SQL Server en Azure SQL-database. Ondersteuning voor reguliere expressies in T-SQL is toegevoegd. Sommige reguliere expressiefuncties zijn niet beschikbaar in alle databasecompatibiliteitsniveaus voor meer informatie. | Reguliere expressiefuncties zoals REGEXP_LIKE, REGEXP_MATCHES en REGEXP_SPLIT_TO_TABLE zijn geïntroduceerd om patroonkoppeling, extractie en splitsing rechtstreeks in T-SQL mogelijk te maken. |
De mogelijkheid om AI-insluitingen (vectormatrices) te maken op basis van tekstexpressies, is toegevoegd aan de database-engine. Zie AI-functies voor meer informatie. | Introduceert de AI_GENERATE_CHUNKS-functie, die het segmenteren van tekstinvoer voor ai-modelverbruik mogelijk maakt, waardoor de integratie met AI-services wordt verbeterd. |
Traditioneel beschermt de Database Engine DML-instructies tegen het Halloween-probleem door een Spool-operator in het queryplan te introduceren of door gebruik te maken van een andere blokkerende operator die al aanwezig is in het plan, zoals een sortering of een hash-overeenkomst. | Geoptimaliseerde Halloween-beveiliging verwijdert onnodige spooloperators en verbetert de queryprestaties tijdens DML-bewerkingen waarbij Halloween-beveiliging vereist is. |
Geparameteriseerde query's kunnen meerdere queryplannen in de cache hebben voor verschillende selectiviteitscategorieën van een parameter. Optimalisatie van parametergevoelige plannen is standaard ingeschakeld in compatibiliteitsniveau 160 voor alleen selectiequery's | Wanneer optimalisatie van parametergevoelige plannen wordt uitgevoerd onder compatibiliteitsniveau 170, is DML-queryondersteuning en ondersteuning ook beschikbaar voor tempdb |
Geparameteriseerde query's met optionele parameters kunnen te maken hebben met suboptimale plannen vanwege het sniffen van parameters. | Optimalisatie van queryplannen voor optionele parameters, waardoor de prestaties worden verbeterd door meer geschikte plannen te genereren voor NULL- en niet-NULL-waarden. |
Verschillen tussen compatibiliteitsniveau 150 en niveau 160
In deze sectie worden nieuwe gedragingen beschreven die zijn geïntroduceerd met compatibiliteitsniveau 160.
Instelling voor compatibiliteitsniveau van 150 of lager | Instelling voor compatibiliteitsniveau van 160 |
---|---|
Geparameteriseerde query's hebben één queryplan op basis van de parameters die worden gebruikt voor de eerste uitvoering. Er wordt slechts één queryplan in de cache opgeslagen en gebruikt voor alle parameterwaarden. Dit kan ertoe leiden dat een queryplan inefficiënt is voor sommige waarden van de parameter, ook wel een parametergevoelig plan genoemd. | Geparameteriseerde query's kunnen meerdere queryplannen in de cache hebben voor verschillende selectiviteitscategorieën van een parameter. Optimalisatie van parametergevoelige plannen is standaard ingeschakeld in compatibiliteitsniveau 160. Zie PSP Optimization voor meer informatie. |
Kardinaliteitschatting maakt gebruik van slechts één standaardset modelveronderstellingen over de onderliggende gegevensdistributie en gebruikspatronen voor alle databases en query's. De enige manier om een van deze veronderstellingen te wijzigen of aan te passen, is wanneer de gebruiker een handmatig proces uitvoert om expliciet aan te geven welke modelveronderstellingen moeten worden gebruikt, met behulp van queryhints. Er kan geen interne aanpassing worden aangebracht aan dit standaardmodel nadat een queryplan is gegenereerd. | Kardinaliteitschatting begint met de standaardset modelveronderstellingen over de onderliggende gegevensdistributie en gebruikspatronen, maar na sommige uitvoeringen voor een bepaalde query leert de Database Engine welke verschillende sets modelveronderstellingen nauwkeurigere schattingen kunnen opleveren en past de veronderstellingen in gebruik aan zodat deze beter overeenkomen met de gegevensset die wordt opgevraagd. CE Feedback is standaard ingeschakeld in compatibiliteitsniveau 160. Zie feedback over kardinaliteitschatting (CE)voor meer informatie. |
Er wordt geen automatische bepaling van de optimale mate van parallelle uitvoering uitgevoerd door de database-engine. Zie Serverconfiguratie voor meer informatie over het handmatig beheren van de maximale mate van parallelle uitvoering (MAXDOP) op het niveau van het exemplaar, de database, de query of de workload : maximale mate van parallelle uitvoering | De mate van parallelle uitvoering (DOP) Feedback verbetert de queryprestaties door inefficiënties voor herhalende query's te identificeren op basis van verstreken tijd en wachttijden. Als het gebruik van parallelle uitvoering als inefficiënt wordt beschouwd, verlaagt DOP-feedback de DOP voor de volgende uitvoering van de query, van wat de geconfigureerde DOP is en controleert u of dit helpt. DOP-feedback is niet standaard ingeschakeld. Als u DOP-feedback wilt inschakelen, schakelt u de configuratie van het DOP_FEEDBACK databasebereik in een database in. Voor meer informatie, zie Feedback over Graad van Parallelisme (DOP). |
Verschillen tussen compatibiliteitsniveau 140 en niveau 150
In deze sectie worden nieuwe gedragingen beschreven die zijn geïntroduceerd met compatibiliteitsniveau 150.
Instelling voor compatibiliteitsniveau van 140 of lager | Instelling voor compatibiliteitsniveau van 150 |
---|---|
Relationele datawarehouse- en analyseworkloads kunnen mogelijk geen columnstore-indexen gebruiken vanwege OLTP-overhead, gebrek aan ondersteuning van leveranciers of andere beperkingen. Zonder columnstore-indexen kunnen deze workloads niet profiteren van de batchuitvoeringsmodus. | De batchuitvoeringsmodus is nu beschikbaar voor analyseworkloads zonder dat columnstore-indexen nodig zijn. Zie de batchmodus in rowstore voor meer informatie. |
Query's in de rijmodus die onvoldoende geheugentoekenningen aanvragen die leiden tot overloop naar de schijf, kunnen problemen blijven ondervinden bij opeenvolgende uitvoeringen. | Query's in de rijmodus die onvoldoende geheugentoekenningen aanvragen die leiden tot overloop naar de schijf, kunnen de prestaties bij opeenvolgende uitvoeringen verbeteren. Zie feedback over het verlenen van feedback over rijmodus voor meer informatie. |
Query's in de rijmodus die een overmatige geheugentoekenningsgrootte aanvragen die tot gelijktijdigheidsproblemen leidt, kunnen problemen blijven ondervinden bij opeenvolgende uitvoeringen. | Query's in de rijmodus die een overmatige geheugentoekenningsgrootte aanvragen, waardoor gelijktijdigheidsproblemen kunnen optreden bij opeenvolgende uitvoeringen. Zie feedback over het verlenen van feedback over rijmodus voor meer informatie. |
Query's die verwijzen naar T-SQL scalaire UDF's maken gebruik van iteratieve aanroep, gebrek aan kosten en forceren van seriële uitvoering. | T-SQL scalaire UDF's worden omgezet in gelijkwaardige relationele expressies die 'inlined' zijn in de aanroepende query, wat vaak resulteert in aanzienlijke prestatieverbeteringen. Zie T-SQL scalaire UDF-inlining voor meer informatie. |
Tabelvariabelen gebruiken een vaste schatting voor de kardinaliteitsraming. Als het werkelijke aantal rijen veel hoger is dan de geraden waarde, kunnen de prestaties van downstreambewerkingen lijden. | Nieuwe plannen gebruiken de werkelijke kardinaliteit van de tabelvariabele die op de eerste compilatie is aangetroffen in plaats van een vaste schatting. Zie tabelvariabele uitgestelde compilatie voor meer informatie. |
Raadpleeg wat er nieuw is in SQL Server 2019 en Intelligente queryverwerking in SQL-databases voor meer informatie over functies voor queryverwerking die zijn ingeschakeld in databasecompatibiliteitsniveau 150.
Verschillen tussen compatibiliteitsniveau 130 en niveau 140
In deze sectie worden nieuwe gedragingen beschreven die zijn geïntroduceerd met compatibiliteitsniveau 140.
Instelling voor compatibiliteitsniveau van 130 of lager | Instelling voor compatibiliteitsniveau van 140 |
---|---|
Kardinaliteitsramingen voor instructies die verwijzen naar tabelwaarden met meerdere instructies, gebruiken een vaste schatting van rijen. | Kardinaliteitschattingen voor in aanmerking komende instructies die verwijzen naar tabelwaardefuncties met meerdere instructies, gebruiken de werkelijke kardinaliteit van de functie-uitvoer. Dit is ingeschakeld via interleaved-uitvoering voor tabelwaardefuncties met meerdere instructies. |
Batchmodusquery's die onvoldoende geheugentoekenningen aanvragen die leiden tot overloop naar de schijf, kunnen problemen blijven ondervinden bij opeenvolgende uitvoeringen. | Batchmodusquery's die onvoldoende geheugentoekenningen aanvragen die leiden tot overloop naar de schijf, hebben mogelijk betere prestaties bij opeenvolgende uitvoeringen. Dit is ingeschakeld via feedback over geheugentoekenningen in de batchmodus , waarmee de geheugentoekenningsgrootte van een in de cache opgeslagen plan wordt bijgewerkt als er lekkages zijn opgetreden voor batchmodusoperators. |
Batchmodusquery's die een overmatige geheugentoekenningsgrootte aanvragen die tot gelijktijdigheidsproblemen leidt, kunnen problemen blijven ondervinden bij opeenvolgende uitvoeringen. | Batchmodusquery's die een overmatige geheugentoekenningsgrootte aanvragen die tot gelijktijdigheidsproblemen leidt, hebben mogelijk een betere gelijktijdigheid bij opeenvolgende uitvoeringen. Dit is ingeschakeld via feedback over het verlenen van geheugen in de batchmodus , waardoor de geheugentoe kennende grootte van een plan in de cache wordt bijgewerkt als er oorspronkelijk een overmatige hoeveelheid is aangevraagd. |
Batchmodusquery's die joinoperators bevatten, komen in aanmerking voor drie fysieke join-algoritmen, waaronder geneste lus, hash-join en samenvoeging. Als kardinaliteitschattingen onjuist zijn voor join-invoer, kan er een ongepast joinalgoritme worden geselecteerd. Als dit gebeurt, zullen de prestaties lijden en blijft het ongepaste join-algoritme in gebruik totdat het in de cache geplaatste plan opnieuw wordt gecompileerd. | Er is een extra joinoperator met de naam Adaptive Join. Als kardinaliteitschattingen onjuist zijn voor de outer build join-invoer, kan er een ongepast join-algoritme worden geselecteerd. Als dit gebeurt en de instructie in aanmerking komt voor een adaptieve join, wordt een geneste lus gebruikt voor kleinere join-invoer en wordt een hash-join gebruikt voor grotere join-invoer dynamisch zonder hercompilatie. |
Triviale plannen die verwijzen naar Columnstore-indexen komen niet in aanmerking voor de uitvoering van batchmodus. | Een triviaal plan dat verwijst naar Columnstore-indexen, wordt verwijderd ten gunste van een plan dat in aanmerking komt voor de uitvoering van de batchmodus. |
De sp_execute_external_script UDX-operator kan alleen worden uitgevoerd in de rijmodus. |
De sp_execute_external_script UDX-operator komt in aanmerking voor uitvoering van batchmodus. |
Functies met tabelwaarde met meerdere instructies (TVF's) hebben geen interleaved uitvoering | Interleaved execution for multi-statement TVFs to improve plan quality. |
Fixes onder traceringsvlag 4199 in eerdere versies van SQL Server vóór SQL Server 2017 zijn nu standaard ingeschakeld. Met de compatibiliteitsmodus 140. Traceringsvlag 4199 is nog steeds van toepassing op nieuwe oplossingen voor queryoptimalisatie die na SQL Server 2017 worden uitgebracht. Zie Trace Flag 4199 voor meer informatie over Trace Flag 4199.
Verschillen tussen compatibiliteitsniveau 120 en niveau 130
In deze sectie worden nieuwe gedragingen beschreven die zijn geïntroduceerd met compatibiliteitsniveau 130.
Instelling voor compatibiliteitsniveau van 120 of lager | Instelling voor compatibiliteitsniveau van 130 |
---|---|
Insert in een INSERT-SELECT-instructie is één thread. | De INSERT in een INSERT-SELECT-instructie is multithreaded of kan een parallel plan hebben. |
Query's in een tabel die is geoptimaliseerd voor geheugen, voeren één thread uit. | Query's in een tabel die is geoptimaliseerd voor geheugen, kunnen nu parallelle plannen hebben. |
De SQL 2014-kardinaliteitsschatter geïntroduceerd CardinalityEstimationModelVersion="120" |
Verdere kardinaliteitschatting (CE) Verbeteringen met het kardinaliteitsramingsmodel 130, dat zichtbaar is vanuit een queryplan. KardinaliteitEstimationModelVersion="130" |
Batchmodus versus rijmoduswijzigingen met Columnstore-indexen:
|
Batchmodus versus rijmoduswijzigingen met Columnstore-indexen:
|
Statistieken kunnen automatisch worden bijgewerkt. | De logica waarmee statistieken automatisch worden bijgewerkt, is agressiever voor grote tabellen. In de praktijk moet dit de gevallen verminderen waarin klanten prestatieproblemen hebben gezien voor query's waarbij nieuwe ingevoegde rijen regelmatig worden opgevraagd, maar waar de statistieken niet zijn bijgewerkt om deze waarden op te nemen. |
Trace 2371 is standaard UITGESCHAKELD in SQL Server 2014 (12.x). |
Trace 2371 is standaard INGESCHAKELD in SQL Server 2016 (13.x). Traceringsvlag 2371 vertelt de updater voor automatische statistieken om een kleinere maar wijzer subset rijen te samplen, in een tabel met een groot aantal rijen. Een verbetering is om in het voorbeeld meer rijen op te nemen die onlangs zijn ingevoegd. Een andere verbetering is het uitvoeren van query's terwijl het updatestatistiekenproces wordt uitgevoerd, in plaats van de query te blokkeren. |
Voor niveau 120 worden statistieken gesampleerd door een proces met één thread. | Voor niveau 130 worden statistieken gesampleed door een proces met meerdere threads (parallel proces). |
253 binnenkomende refererende sleutels is de limiet. | Naar een bepaalde tabel kan worden verwezen door maximaal 10.000 binnenkomende refererende sleutels of vergelijkbare verwijzingen. Zie Refererende-sleutelrelaties maken voor beperkingen. |
De afgeschafte MD2-, MD4-, MD5-, SHA- en SHA1-hashalgoritmen zijn toegestaan. | Alleen SHA2_256 en SHA2_512 hash-algoritmen zijn toegestaan. |
SQL Server 2016 (13.x) bevat verbeteringen in sommige gegevenstypenconversies en sommige (meestal ongebruikelijke) bewerkingen. Zie Verbeteringen in SQL Server en Azure SQL Database voor het verwerken van bepaalde gegevenstypen en ongebruikelijke bewerkingen voor meer informatie. | |
De STRING_SPLIT functie is niet beschikbaar. |
De STRING_SPLIT functie is beschikbaar onder compatibiliteitsniveau 130 of hoger. Als uw databasecompatibiliteitsniveau lager is dan 130, kan SQL Server de functie niet vinden en uitvoeren STRING_SPLIT . |
Fixes die zijn uitgevoerd onder traceringsvlag 4199 in eerdere versies van SQL Server vóór SQL Server 2016 (13.x) zijn nu standaard ingeschakeld. Met de compatibiliteitsmodus 130. Traceringsvlag 4199 is nog steeds van toepassing op nieuwe oplossingen voor queryoptimalisatie die worden uitgebracht na SQL Server 2016 (13.x). Als u de oudere queryoptimalisatie in SQL Database wilt gebruiken, moet u compatibiliteitsniveau 110 selecteren. Zie Trace Flag 4199 voor meer informatie over Trace Flag 4199.
Verschillen tussen lagere compatibiliteitsniveaus en niveau 120
In deze sectie worden nieuwe gedragingen beschreven die zijn geïntroduceerd met compatibiliteitsniveau 120.
Instelling voor compatibiliteitsniveau van 110 of lager | Instelling voor compatibiliteitsniveau van 120 |
---|---|
De oudere queryoptimalisatie wordt gebruikt. | SQL Server 2014 (12.x) bevat aanzienlijke verbeteringen in het onderdeel waarmee queryplannen worden gemaakt en geoptimaliseerd. Deze nieuwe functie voor queryoptimalisatie is afhankelijk van het gebruik van het databasecompatibiliteitsniveau 120. Nieuwe databasetoepassingen moeten worden ontwikkeld met databasecompatibiliteitsniveau 120 om te profiteren van deze verbeteringen. Toepassingen die zijn gemigreerd vanuit eerdere versies van SQL Server, moeten zorgvuldig worden getest om te controleren of goede prestaties worden onderhouden of verbeterd. Als de prestaties afnemen, kunt u het compatibiliteitsniveau van de database instellen op 110 of eerder om de oudere methodologie voor queryoptimalisatie te gebruiken. Databasecompatibiliteitsniveau 120 maakt gebruik van een nieuwe kardinaliteitsschatter die is afgestemd op moderne datawarehousing en OLTP-workloads. Voordat u databasecompatibiliteitsniveau instelt op 110 vanwege prestatieproblemen, raadpleegt u de aanbevelingen in de sectie Queryplannen van nieuw in SQL Server 2016. |
In compatibiliteitsniveaus lager dan 120 wordt de taalinstelling genegeerd bij het converteren van een datumwaarde naar een tekenreekswaarde. Dit gedrag is alleen specifiek voor het datumtype . Zie voorbeeld B in de sectie Voorbeelden . | De taalinstelling wordt niet genegeerd bij het converteren van een datumwaarde naar een tekenreekswaarde. |
Recursieve verwijzingen aan de rechterkant van een EXCEPT component maken een oneindige lus. Voorbeeld C in de sectie Voorbeelden laat dit gedrag zien. |
Recursieve verwijzingen in een EXCEPT component genereren een fout in overeenstemming met de ANSI SQL-standaard. |
Recursieve algemene tabelexpressie (CTE) staat dubbele kolomnamen toe. | Recursieve CTE staat geen dubbele kolomnamen toe. |
Uitgeschakelde triggers worden ingeschakeld als de triggers worden gewijzigd. | Als u een trigger wijzigt, wordt de status (ingeschakeld of uitgeschakeld) van de trigger niet gewijzigd. |
De component OUTPUT INTO-tabel negeert de IDENTITY_INSERT SETTING = OFF en staat toe dat expliciete waarden worden ingevoegd. |
U kunt geen expliciete waarden invoegen voor een identiteitskolom in een tabel wanneer IDENTITY_INSERT deze is ingesteld op UIT. |
Wanneer de databaseinsluiting is ingesteld op gedeeltelijk, kan het valideren van het $action veld in de OUTPUT component van een MERGE instructie een sorteringsfout retourneren. |
De sortering van de waarden die door de $action component van een MERGE instructie worden geretourneerd, is de databasesortering in plaats van de serversortering en er wordt geen conflict met sortering geretourneerd. |
Met SELECT INTO een instructie wordt altijd een invoegbewerking met één thread gemaakt. |
Een SELECT INTO instructie kan een parallelle invoegbewerking maken. Bij het invoegen van een groot aantal rijen kan de parallelle bewerking de prestaties verbeteren. |
Verschillen tussen lagere compatibiliteitsniveaus en niveaus 100 en 110
In deze sectie worden nieuwe gedragingen beschreven die zijn geïntroduceerd met compatibiliteitsniveau 110. Deze sectie is ook van toepassing op compatibiliteitsniveaus boven de 110.
Instelling voor compatibiliteitsniveau van 100 of lager | Instelling op compatibiliteitsniveau van ten minste 110 |
---|---|
Common Language Runtime -databaseobjecten (CLR) worden uitgevoerd met versie 4 van de CLR. Sommige gedragswijzigingen die zijn geïntroduceerd in versie 4 van de CLR, worden echter vermeden. Zie Wat is er nieuw in CLR-integratie? | CLR-databaseobjecten worden uitgevoerd met versie 4 van de CLR. |
De XQuery-functie tekenreekslengte en subtekenreeks tellen elke surrogaat als twee tekens. | De XQuery-functies tekenreekslengte en subtekenreeks tellen elke surrogaat als één teken. |
PIVOT is toegestaan in een recursieve CTE-query (Common Table Expression). De query retourneert echter onjuiste resultaten wanneer er meerdere rijen per groepering zijn. |
PIVOT is niet toegestaan in een recursieve CTE-query (Common Table Expression). Er wordt een fout geretourneerd. |
Het RC4-algoritme wordt alleen ondersteund voor achterwaartse compatibiliteit. Nieuw materiaal kan alleen worden versleuteld met RC4 of RC4_128 wanneer de database compatibiliteitsniveau 90 of 100 heeft. (Niet aanbevolen.) In SQL Server 2012 (11.x) kan materiaal dat is versleuteld met RC4 of RC4_128 worden ontsleuteld in elk compatibiliteitsniveau. | Nieuw materiaal kan niet worden versleuteld met RC4 of RC4_128. Gebruik in plaats daarvan een nieuwer algoritme, zoals een van de AES-algoritmen. In SQL Server 2012 (11.x) kan materiaal dat is versleuteld met RC4 of RC4_128 worden ontsleuteld in elk compatibiliteitsniveau. |
De standaardstijl voor en bewerkingen op CAST CONVERT - en datum/tijd2-gegevenstypen is 121, behalve wanneer een van beide typen wordt gebruikt in een berekende kolomexpressie. Voor berekende kolommen is de standaardstijl 0. Dit gedrag is van invloed op berekende kolommen wanneer ze worden gemaakt, gebruikt in query's met betrekking tot automatische parameterisatie of worden gebruikt in beperkingsdefinities.Voorbeeld D in de sectie Voorbeelden toont het verschil tussen stijlen 0 en 121. Het laat het hierboven beschreven gedrag niet zien. Zie CAST en CONVERT voor meer informatie over datum- en tijdstijlen. |
Onder compatibiliteitsniveau 110 is de standaardstijl voor en bewerkingen op CAST CONVERT - en datum/tijd2-gegevenstypen altijd 121. Als uw query afhankelijk is van het oude gedrag, gebruikt u een compatibiliteitsniveau kleiner dan 110 of geeft u expliciet de stijl 0 op in de betreffende query.Als u de database bijwerken naar compatibiliteitsniveau 110, worden gebruikersgegevens die zijn opgeslagen op schijf niet gewijzigd. U moet deze gegevens naar wens handmatig corrigeren. Als u bijvoorbeeld een tabel hebt gemaakt SELECT INTO op basis van een bron die een berekende kolomexpressie bevat die hierboven wordt beschreven, worden de gegevens (met stijl 0) opgeslagen in plaats van de berekende kolomdefinitie zelf. U moet deze gegevens handmatig bijwerken zodat deze overeenkomen met stijl 121. |
De operator + (Optellen) kan worden toegepast op een operand van het type datum, tijd, datum/tijd2 of datetimeoffset als de andere operand datum/tijd of smalldatetime heeft getypt. | Als u de opteloperator probeert toe te passen op een operand van het type datum, tijd, datum/tijd2 of datetimeoffset en een operand van het type datum/tijd of smalldatetime, wordt fout 402 veroorzaakt. |
Kolommen in externe tabellen van het type smalldatetime waarnaar wordt verwezen in een gepartitioneerde weergave, worden toegewezen als datum/tijd. Overeenkomende kolommen in lokale tabellen (in dezelfde rangschikkelijke positie in de selectielijst) moeten van het type datum/tijd zijn. | Kolommen in externe tabellen van het type smalldatetime waarnaar wordt verwezen in een gepartitioneerde weergave, worden toegewezen als smalldatetime. Overeenkomende kolommen in lokale tabellen (in dezelfde rangschikkelijke positie in de selectielijst) moeten van het type smalldatetime zijn. Na een upgrade naar 110 mislukt de gedistribueerde gepartitioneerde weergave omdat het gegevenstype niet overeenkomt. U kunt dit oplossen door het gegevenstype in de externe tabel te wijzigen in datum/tijd of door het compatibiliteitsniveau van de lokale database in te stellen op 100 of lager. |
SOUNDEX met de functie worden de volgende regels geïmplementeerd:1) Hoofdletter H of hoofdletter W wordt genegeerd bij het scheiden van twee medeklinkers met hetzelfde getal in de SOUNDEX code.2) Als de eerste twee tekens van character_expression hetzelfde getal in de SOUNDEX code hebben, worden beide tekens opgenomen. Als een set naast elkaar-medeklinkers hetzelfde nummer in de SOUNDEX code hebben, worden ze allemaal uitgesloten, behalve de eerste. |
SOUNDEX met de functie worden de volgende regels geïmplementeerd:1) Als hoofdletter H of hoofdletterS W twee medeklinkers met hetzelfde getal in de SOUNDEX code scheiden, wordt de medeklinker aan de rechterkant genegeerd2) Als een set naast elkaars medeklinkers hetzelfde nummer in de SOUNDEX code heeft, worden ze allemaal uitgesloten, behalve de eerste.De aanvullende regels kunnen ertoe leiden dat de waarden die door de SOUNDEX functie worden berekend, afwijken van de waarden die zijn berekend onder eerdere compatibiliteitsniveaus. Na een upgrade naar compatibiliteitsniveau 110 moet u mogelijk de indexen, heaps of CHECK-beperkingen die gebruikmaken van de SOUNDEX functie opnieuw opbouwen. Zie SOUNDEX voor meer informatie. |
STRING_AGG is beschikbaar zonder <order_clause> een . |
STRING_AGG is beschikbaar met een optioneel <order_clause> . Zie STRING_AGG voor meer informatie |
Verschillen tussen compatibiliteitsniveau 90 en niveau 100
In deze sectie worden nieuwe gedragingen beschreven die zijn geïntroduceerd met compatibiliteitsniveau 100.
Instelling voor compatibiliteitsniveau van 90 | Instelling voor compatibiliteitsniveau van 100 | Mogelijkheid van impact |
---|---|---|
De QUOTED_IDENTIFIER-instelling is altijd ingesteld op AAN voor functies met meerdere waarden in de tabelwaarde wanneer deze worden gemaakt, ongeacht de instelling op sessieniveau. | De sessie-instelling TUSSEN AANTEKENing wordt uitgevoerd wanneer functies met meerdere waarden in tabelwaarden worden gemaakt. | Gemiddeld |
Wanneer u een partitiefunctie maakt of wijzigt, worden letterlijke gegevens voor datum/tijd en smalldatetime in de functie geëvalueerd, ervan uitgaande dat US_English als taalinstelling. | De huidige taalinstelling wordt gebruikt voor het evalueren van de letterlijke waarde voor datum/tijd en smalldatetime in de partitiefunctie. | Gemiddeld |
De FOR BROWSE component is toegestaan (en genegeerd) in INSERT en SELECT INTO instructies. |
De FOR BROWSE component is niet toegestaan in INSERT en SELECT INTO instructies. |
Gemiddeld |
Predicaten voor volledige tekst zijn toegestaan in de OUTPUT component. |
Predicaten voor volledige tekst zijn niet toegestaan in de OUTPUT component. |
Laag |
CREATE FULLTEXT STOPLIST , ALTER FULLTEXT STOPLIST en DROP FULLTEXT STOPLIST worden niet ondersteund. De systeemstoplijst wordt automatisch gekoppeld aan nieuwe volledige-tekstindexen. |
CREATE FULLTEXT STOPLIST , ALTER FULLTEXT STOPLIST en DROP FULLTEXT STOPLIST worden ondersteund. |
Laag |
MERGE wordt niet afgedwongen als een gereserveerd trefwoord. |
MERGE is een volledig gereserveerd trefwoord. De MERGE instructie wordt ondersteund onder zowel 100 als 90 compatibiliteitsniveaus. |
Laag |
Als u het <dml_table_source> argument van de INSERT-instructie gebruikt, wordt een syntaxisfout gegenereerd. |
U kunt de resultaten van een OUTPUT-component vastleggen in een geneste instructie INSERT, UPDATE, DELETE of MERGE en deze resultaten invoegen in een doeltabel of -weergave. Dit gebeurt met behulp van het <dml_table_source> argument van de INSERT-instructie. |
Laag |
NOINDEX Tenzij is opgegeven of DBCC CHECKDB DBCC CHECKTABLE zowel fysieke als logische consistentiecontroles uitvoert op één tabel of geïndexeerde weergave en op alle niet-geclusterde en XML-indexen. Ruimtelijke indexen worden niet ondersteund. |
NOINDEX Tenzij dit is opgegeven of DBCC CHECKDB DBCC CHECKTABLE zowel fysieke als logische consistentiecontroles uitvoert op één tabel en op alle niet-geclusterde indexen. Bij XML-indexen, ruimtelijke indexen en geïndexeerde weergaven worden echter standaard alleen fysieke consistentiecontroles uitgevoerd.Als WITH EXTENDED_LOGICAL_CHECKS dit is opgegeven, worden logische controles uitgevoerd voor geïndexeerde weergaven, XML-indexen en ruimtelijke indexen, waar aanwezig. Fysieke consistentiecontroles worden standaard uitgevoerd vóór de logische consistentiecontroles. Als NOINDEX ook is opgegeven, worden alleen de logische controles uitgevoerd. |
Laag |
Wanneer een OUTPUT-component wordt gebruikt met een DML-instructie (Data Manipulat Language) en er een runtimefout optreedt tijdens de uitvoering van de instructie, wordt de hele transactie beëindigd en teruggedraaid. | Wanneer een OUTPUT component wordt gebruikt met een DML-instructie (Data Manipulat Language) en er een runtimefout optreedt tijdens de uitvoering van de instructie, is het gedrag afhankelijk van de SET XACT_ABORT instelling. Als SET XACT_ABORT off is, wordt de instructie beëindigd door een instructie die is gegenereerd door de DML-instructie met behulp van de OUTPUT component, maar wordt de uitvoering van de batch voortgezet en wordt de transactie niet teruggedraaid. Als SET XACT_ABORT on is, worden alle runtimefouten die zijn gegenereerd door de DML-instructie met behulp van de OUTPUT-component de batch beëindigd en wordt de transactie teruggedraaid. |
Laag |
KUBUS en ROLLUP worden niet afgedwongen als gereserveerde trefwoorden. |
CUBE en ROLLUP zijn gereserveerde trefwoorden binnen de GROUP BY-component. |
Laag |
Strikte validatie wordt toegepast op elementen van het XML anyType-type . | Lax-validatie wordt toegepast op elementen van het anyType-type . Zie Onderdelen van jokertekens en inhoudsvalidatie voor meer informatie. | Laag |
De speciale kenmerken xsi:nil en xsi:type kunnen niet worden opgevraagd of gewijzigd door taalinstructies voor gegevensmanipulatie. Dit betekent dat /e/@xsi:nil dit mislukt terwijl /e/@* de kenmerken xsi:nil en xsi:type worden genegeerd.
/e Retourneert echter de kenmerken xsi:nil en xsi:type voor consistentie met SELECT xmlCol , zelfs als xsi:nil = "false" . |
De speciale kenmerken xsi:nil en xsi:type worden opgeslagen als reguliere kenmerken en kunnen worden opgevraagd en gewijzigd. Als u bijvoorbeeld de query SELECT x.query('a/b/@*') uitvoert, worden alle kenmerken geretourneerd, waaronder xsi:nil en xsi:type. Als u deze typen in de query wilt uitsluiten, vervangt u deze door @* @*[namespace-uri(.) != " de xsi-naamruimte-URI" in te voegen en niet (local-name(.) = "type" of local-name(.) ="nil" . |
Laag |
Een door de gebruiker gedefinieerde functie waarmee een XML-constante tekenreekswaarde wordt geconverteerd naar een datum/tijd-type van SQL Server, wordt gemarkeerd als deterministisch. | Een door de gebruiker gedefinieerde functie waarmee een XML-constante tekenreekswaarde wordt geconverteerd naar een datum/tijd-type van SQL Server, wordt gemarkeerd als niet-deterministisch. | Laag |
De XML-samenvoeg- en lijsttypen worden niet volledig ondersteund. | De samenvoeg- en lijsttypen worden volledig ondersteund, inclusief de volgende functionaliteit: Samenvoeging van lijst Union of union Lijst met atomische typen Lijst met samenvoeging |
Laag |
De SET-opties die vereist zijn voor een xQuery-methode worden niet gevalideerd wanneer de methode is opgenomen in een weergave- of inline-tabelwaardefunctie. | De SET-opties die vereist zijn voor een xQuery-methode worden gevalideerd wanneer de methode is opgenomen in een weergave- of inline-tabelwaardefunctie. Er treedt een fout op als de SET-opties van de methode onjuist zijn ingesteld. | Laag |
XML-kenmerkwaarden die einde-of-regeltekens (regelterugloop en regelfeed) bevatten, worden niet genormaliseerd volgens de XML-standaard. Dat wil gezegd, beide tekens worden geretourneerd in plaats van één regelinvoerteken. | XML-kenmerkwaarden die einde-of-regeltekens (regelterugloop en regelfeed) bevatten, worden genormaliseerd volgens de XML-standaard. Dat wil gezegd: alle regeleinden in externe geparseerde entiteiten (inclusief de documententiteit) worden genormaliseerd op invoer door zowel de reeks met twee tekens #xD #xA als alle #xD die niet worden gevolgd door #xA naar één #xA teken te vertalen. Toepassingen die gebruikmaken van kenmerken voor het transporteren van tekenreekswaarden die einde-of-regeltekens bevatten, ontvangen deze tekens niet terug wanneer ze worden verzonden. Gebruik de XML-numerieke tekenentiteiten om alle end-of-line tekens te coderen om het normalisatieproces te voorkomen. |
Laag |
De kolomeigenschappen ROWGUIDCOL en IDENTITY kunnen onjuist worden benoemd als een beperking. De instructie CREATE TABLE T (C1 int CONSTRAINT MyConstraint IDENTITY) wordt bijvoorbeeld uitgevoerd, maar de naam van de beperking blijft niet behouden en is niet toegankelijk voor de gebruiker. |
De kolomeigenschappen ROWGUIDCOL en IDENTITY kunnen niet worden benoemd als een beperking. Fout 156 wordt geretourneerd. |
Laag |
Kolommen bijwerken met behulp van een tweerichtingstoewijzing, zoals UPDATE T1 SET @v = column_name = <expression> onverwachte resultaten, omdat de livewaarde van de variabele kan worden gebruikt in andere componenten, zoals de en WHERE component tijdens de uitvoering van de ON instructie in plaats van de beginwaarde van de instructie. Dit kan ertoe leiden dat de betekenissen van de predicaten onvoorspelbaar zijn per rij.Dit gedrag is alleen van toepassing wanneer het compatibiliteitsniveau is ingesteld op 90. |
Het bijwerken van kolommen met behulp van een tweerichtingstoewijzing levert verwachte resultaten op omdat alleen de beginwaarde van de instructie van de kolom wordt geopend tijdens de uitvoering van de instructie. | Laag |
Variabeletoewijzing is toegestaan in een instructie met een operator op het hoogste niveau UNION , maar retourneert onverwachte resultaten. Meer informatie in voorbeeld E. |
Variabeletoewijzing is niet toegestaan in een instructie die een UNION-operator op het hoogste niveau bevat. Fout 10734 wordt geretourneerd. Zoek een voorgestelde herschrijffunctie in voorbeeld E. | Laag |
De ODBC-functie {fn CONVERT()} gebruikt de standaarddatumnotatie van de taal. Voor sommige talen is de standaardindeling YDM, wat kan leiden tot conversiefouten wanneer CONVERTEREN() wordt gecombineerd met andere functies, zoals {fn CURDATE()} , die een YMD-indeling verwachten. |
De ODBC-functie {fn CONVERT()} gebruikt stijl 121 (een taalonafhankelijke YMD-indeling) bij het converteren naar de ODBC-gegevenstypen SQL_TIMESTAMP, SQL_DATE, SQL_TIME, SQLDATE, SQL_TYPE_TIME en SQL_TYPE_TIMESTAMP. |
Laag |
Datum/tijd-intrinsieke waarden, zoals DATEPART geen tekenreeksinvoerwaarden, moeten geldige letterlijke waarden voor datum/tijd zijn. Compileert bijvoorbeeld SELECT DATEPART (year, '2007/05-30') met succes. |
Datum/tijd-intrinsieke waarden, zoals DATEPART vereisen dat tekenreeksinvoerwaarden geldige letterlijke datum/tijd zijn. Fout 241 wordt geretourneerd wanneer een ongeldige letterlijke datum/tijd wordt gebruikt. |
Laag |
Volgspaties die zijn opgegeven in de eerste invoerparameter voor de functie REPLACE, worden bijgesneden wanneer de parameter van het type teken is. In de instructie SELECT '<' + REPLACE(CONVERT(char(6), 'ABC '), ' ', 'L') + '>' wordt de waarde 'ABC ' bijvoorbeeld onjuist geëvalueerd als 'ABC' . |
Volgspaties blijven altijd behouden. Voor toepassingen die afhankelijk zijn van het vorige gedrag van de functie, gebruikt u de RTRIM functie bij het opgeven van de eerste invoerparameter voor de functie. Met de volgende syntaxis wordt bijvoorbeeld het gedrag van SQL Server 2005 gereproduceerd: SELECT '<' + REPLACE(RTRIM(CONVERT(char(6), 'ABC ')), ' ', 'L') + '>' . |
Laag |
Gereserveerde trefwoorden
De compatibiliteitsinstelling bepaalt ook de trefwoorden die zijn gereserveerd door de database-engine. In de volgende tabel ziet u de gereserveerde trefwoorden die door elk van de compatibiliteitsniveaus worden geïntroduceerd.
Instelling voor compatibiliteitsniveau | Gereserveerde trefwoorden |
---|---|
130 |
Te bepalen. |
120 |
Geen. |
110 |
WITHIN GROUP
TRY_CONVERT , SEMANTICKEYPHRASETABLE , SEMANTICSIMILARITYDETAILSTABLE SEMANTICSIMILARITYTABLE |
100 |
CUBE , , MERGE ROLLUP |
90 |
EXTERNAL
PIVOT , UNPIVOT , REVERT TABLESAMPLE |
Op een bepaald compatibiliteitsniveau bevatten de gereserveerde trefwoorden alle trefwoorden die op of onder dat niveau zijn geïntroduceerd. Voor toepassingen op niveau 110 zijn dus alle trefwoorden die in de voorgaande tabel worden vermeld, gereserveerd. Op de lagere compatibiliteitsniveaus blijven trefwoorden op niveau 100 geldige objectnamen, maar de taalfuncties op niveau 110 die overeenkomen met die trefwoorden zijn niet beschikbaar.
Na de introductie blijft een trefwoord gereserveerd. Het gereserveerde trefwoord PIVOT, dat is geïntroduceerd in compatibiliteitsniveau 90, is bijvoorbeeld ook gereserveerd in niveaus 100, 110 en 120.
Als een toepassing een id gebruikt die is gereserveerd als trefwoord voor het compatibiliteitsniveau, mislukt de toepassing. Als u dit wilt omzeilen, plaatst u de id tussen vierkante haken ([]) of aanhalingstekens (""); Als u bijvoorbeeld een toepassing wilt upgraden die gebruikmaakt van de id EXTERNAL
naar compatibiliteitsniveau 90, kunt u de id wijzigen in of [EXTERNAL]
"EXTERNAL"
.
Zie Gereserveerde trefwoorden voor meer informatie.
Machtigingen
Vereist ALTER
machtiging voor de database.
Voorbeelden
Eén. Het compatibiliteitsniveau wijzigen
In het volgende voorbeeld wordt het compatibiliteitsniveau van de AdventureWorks2022
voorbeelddatabase gewijzigd in 150, de standaardwaarde voor SQL Server 2019 (15.x).
ALTER DATABASE AdventureWorks2022
SET COMPATIBILITY_LEVEL = 150;
GO
In het volgende voorbeeld wordt het compatibiliteitsniveau van de huidige database geretourneerd.
SELECT name,
compatibility_level
FROM sys.databases
WHERE name = db_name();
GO
B. De INSTRUCTIE SET LANGUAGE negeren, behalve onder compatibiliteitsniveau 120 of hoger
De volgende query negeert de SET LANGUAGE
instructie, behalve onder compatibiliteitsniveau 120 of hoger.
SET DATEFORMAT dmy;
DECLARE @t2 AS DATE = '12/5/2011';
SET LANGUAGE dutch;
SELECT CONVERT (VARCHAR (11), @t2, 106);
GO
Resultaten wanneer het compatibiliteitsniveau kleiner is dan 120: 12 May 2011
Resultaten wanneer het compatibiliteitsniveau is ingesteld op 120 of hoger: 12 mei 2011
C. Voor instelling op compatibiliteitsniveau van 110 of lager maken recursieve verwijzingen aan de rechterkant van een EXCEPT-component een oneindige lus
WITH cte AS
(SELECT * FROM (VALUES (1), (2), (3)) AS 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. Het verschil tussen stijlen 0 en 121
Wanneer het compatibiliteitsniveau lager is dan 110, is de standaardstijl voor en bewerkingen op CAST
CONVERT
en datum/tijd2-gegevenstypen 121, behalve wanneer een van beide typen wordt gebruikt in een berekende kolomexpressie. Voor berekende kolommen is de standaardstijl 0.
Wanneer het compatibiliteitsniveau 110 of hoger is, is de standaardstijl voor CAST
en bewerkingen op CONVERT
en datum/tijd2 altijd 121. Zie Verschillen tussen lagere compatibiliteitsniveaus en niveaus 100 en 110 voor meer informatie.
Zie CAST en CONVERT voor meer informatie over datum- en tijdstijlen.
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
Dit retourneert resultaten zoals de volgende:
TimeStyle0 | TimeStyle121 | Datetime2Style0 | Datetime2Style121 |
---|---|---|---|
15:15 | 15:15:35.8100000 | 7 juni 2011 17:15 | 2011-06-07 15:15:35.8130000 |
E. Variabele toewijzing - UNION-operator op het hoogste niveau
Onder de instelling voor databasecompatibiliteitsniveau van 90 is variabeletoewijzing toegestaan in een instructie met een UNION-operator op het hoogste niveau, maar retourneert onverwachte resultaten. In de volgende instructies wordt bijvoorbeeld de waarde van de kolom @v
uit de samenvoeging van twee tabellen toegewezen aan de lokale variabeleBusinessEntityID
. Wanneer de SELECT-instructie per definitie meer dan één waarde retourneert, wordt de variabele de laatste waarde toegewezen die wordt geretourneerd. In dit geval wordt de variabele correct toegewezen aan de laatste waarde, maar de resultatenset van de INSTRUCTIE SELECT UNION wordt ook geretourneerd.
ALTER DATABASE AdventureWorks2022
SET COMPATIBILITY_LEVEL = 110;
GO
USE AdventureWorks2022;
GO
DECLARE @v AS INT;
SELECT @v = BusinessEntityID
FROM HumanResources.Employee
UNION ALL
SELECT @v = BusinessEntityID
FROM HumanResources.EmployeeAddress;
SELECT @v;
Onder de instelling voor databasecompatibiliteitsniveau van 100 en hoger is variabeletoewijzing niet toegestaan in een instructie met een operator op het hoogste niveau van UNION. Fout 10734 wordt geretourneerd.
Als u de fout wilt oplossen, herschrijft u de query, zoals wordt weergegeven in het volgende voorbeeld.
DECLARE @v AS INT;
SELECT @v = BusinessEntityID
FROM (SELECT BusinessEntityID
FROM HumanResources.Employee
UNION ALL
SELECT BusinessEntityID
FROM HumanResources.EmployeeAddress) AS Test;
SELECT @v;
Verwante inhoud
- Prestatiestabiliteit behouden tijdens de upgrade naar nieuwere SQL Server
- Het compatibiliteitsniveau van de database wijzigen en Query Store gebruiken
- Compatibiliteitscertificering
- ALTER DATABASE (Transact-SQL)
- Databases upgraden met behulp van de queryafstemmingsassistent
- DATABASE MAKEN
- het compatibiliteitsniveau van een database weergeven of wijzigen
- Query Store-hints