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 ServerAzure SQL DatabaseAzure SQL Managed Instance
Tabellen die zijn geoptimaliseerd voor geheugen, worden gemaakt met (CREATE TABLETransact-SQL).
Tabellen die zijn geoptimaliseerd voor geheugen zijn standaard volledig duurzaam en, net als transacties in (traditionele) tabellen op schijftabellen, zijn transacties in tabellen die zijn geoptimaliseerd voor geheugen volledig atomair, consistent, geïsoleerd en duurzaam (ACID). Tabellen die zijn geoptimaliseerd voor geheugen en native gecompileerde opgeslagen procedures ondersteunen slechts een subset van Transact-SQL functies.
Vanaf SQL Server 2016 en in Azure SQL Database zijn er geen beperkingen voor sorteringen of codepagina's die specifiek zijn voor In-Memory OLTP.
De primaire opslag voor tabellen die zijn geoptimaliseerd voor geheugen is het hoofdgeheugen. Rijen in de tabel worden uit het geheugen gelezen en naar het geheugen geschreven. Een tweede kopie van de tabelgegevens wordt op schijf bewaard, maar alleen voor duurzaamheidsdoeleinden. Zie Opslag voor memory-optimized-objecten maken en beheren voor meer informatie over duurzame tabellen. Gegevens in tabellen die zijn geoptimaliseerd voor geheugen, worden alleen van de schijf gelezen tijdens het herstellen van de database (bijvoorbeeld na het opnieuw opstarten van de server).
Voor nog grotere prestatieverbeteringen ondersteunt In-Memory OLTP duurzame tafels met vertraagde transactieduurzaamheid. Vertraagde duurzame transacties worden kort nadat de transactie is vastgelegd op schijf opgeslagen en de controle wordt teruggegeven aan de client. In ruil voor de verbeterde prestaties gaan vastgelegde transacties die niet op schijf worden bewaard, verloren door een servercrash of failover.
Naast de standaardtabellen die zijn geoptimaliseerd voor duurzaam geheugen, biedt SQL Server ook ondersteuning voor tabellen die niet zijn geoptimaliseerd voor duurzaam geheugen, die niet worden geregistreerd en waarvan de gegevens niet op schijf worden bewaard. Dit betekent dat voor transacties in deze tabellen geen schijf-IO nodig is, maar dat de gegevens verloren gaan als er een servercrash of failover is.
In-Memory OLTP is geïntegreerd met SQL Server om een naadloze ervaring te bieden op alle gebieden, zoals ontwikkeling, implementatie, beheerbaarheid en ondersteuning. Een database kan zowel in-memory als schijfgebaseerde objecten bevatten.
Rijen in tabellen die voor het geheugen zijn geoptimaliseerd, hebben een versiebeheer. Dit betekent dat elke rij in de tabel mogelijk meerdere versies heeft. Alle rijversies worden onderhouden in dezelfde tabelgegevensstructuur. Rijversiebeheer wordt gebruikt om gelijktijdig lezen en schrijven op dezelfde rij toe te staan. Zie Transacties met geheugen-geoptimaliseerde Tabellen voor meer informatie over gelijktijdige leesbewerkingen en schrijfbewerkingen op dezelfde rij.
De volgende afbeelding illustreert multiversiebeheer. De figuur toont een tabel met drie rijen en elke rij heeft verschillende versies.
De tafel heeft drie rijen: r1, r2 en r3. R1 heeft drie versies, R2 heeft twee versies en R3 heeft vier versies. Verschillende versies van dezelfde rij nemen niet noodzakelijkerwijs opeenvolgende geheugenlocaties in beslag. De verschillende rijversies kunnen worden verspreid over de gegevensstructuur van de tabel.
De voor geheugen geoptimaliseerde tabelgegevensstructuur kan worden gezien als een verzameling rijversies. Rijen in schijftabellen zijn geordend in pagina's en gebieden, en afzonderlijke rijen worden geadresseerd met behulp van paginanummer en pagina-offset, rijversies in tabellen die zijn geoptimaliseerd voor geheugen, worden geadresseerd met behulp van geheugenaanwijzers van 8 bytes.
Gegevens in tabellen die zijn geoptimaliseerd voor geheugen, worden op twee manieren geopend:
Via systeemeigen gecompileerde opgeslagen procedures.
Met geïnterpreteerde Transact-SQL, buiten een systeemeigen gecompileerde stored procedure. Deze Transact-SQL verklaringen kunnen zich binnen geïnterpreteerde opgeslagen procedures bevinden of ze kunnen ad hoc Transact-SQL verklaringen zijn.
Toegang tot gegevens in memory-optimized-tabellen
Voor geheugen geoptimaliseerde tabellen kunnen het efficiëntst worden benaderd vanuit systeemeigen gecompileerde opgeslagen procedures (Natively Compiled Stored Procedures). Voor geheugen geoptimaliseerde tabellen kunnen ook worden benaderd met (traditioneel) geïnterpreteerde Transact-SQL. Geïnterpreteerd Transact-SQL verwijst naar toegang tot voor geheugen geoptimaliseerde tabellen zonder een native gecompileerde opgeslagen procedure. Enkele voorbeelden van geïnterpreteerde Transact-SQL toegang zijn toegang tot een voor geheugen geoptimaliseerde tabel via een DML-trigger, ad-hoc Transact-SQL batch-, weergave- en tabelgewaardeerde functie.
De volgende tabel geeft een overzicht van de native en geïnterpreteerde Transact-SQL toegang voor verschillende objecten.
| Kenmerk | Toegang via een systeemeigen gecompileerde opgeslagen procedure | Geïnterpreteerde Transact-SQL-toegang | CLR-toegang |
|---|---|---|---|
| Tabel geoptimaliseerd voor geheugen | Ja | Ja | Nr.1 |
| Tabeltype dat is geoptimaliseerd voor geheugen | Ja | Ja | Nee. |
| Systeemeigen gecompileerde opgeslagen procedure | Nesten van systeemeigen gecompileerde opgeslagen procedures wordt nu ondersteund. U kunt de syntaxis EXECUTE gebruiken in de opgeslagen procedures, zolang de procedure waarnaar wordt verwezen ook native is gecompileerd. | Ja | Nee* |
1U hebt geen toegang tot een voor geheugen geoptimaliseerde tabel of een systeemeigen gecompileerde opgeslagen procedure via de contextverbinding (de verbinding van SQL Server bij het uitvoeren van een CLR-module). U kunt echter een andere verbinding maken en openen van waaruit u toegang hebt tot voor geheugen geoptimaliseerde tabellen en native gecompileerde opgeslagen procedures.
Gevoelige gegevens in tabellen die zijn geoptimaliseerd voor geheugen, kunnen worden beveiligd met behulp van Always Encrypted. De volgende beperkingen zijn van toepassing:
- Wanneer u Always Encrypted gebruikt met beveiligde enclaves, wordt het gebruik van enclave-compatibele sleutels voor kolommen in tabellen die zijn geoptimaliseerd voor geheugen niet ondersteund. Dit betekent dat in-place encryptie niet kan worden gebruikt en dat de initiële encryptie op de client wordt uitgevoerd.
- Always Encrypted wordt niet ondersteund voor kolommen in een tabel die is geoptimaliseerd voor geheugen wanneer naar de tabel wordt verwezen in een systeemeigen gecompileerde module.
Prestaties en schaalbaarheid
De volgende factoren zijn van invloed op de prestatiewinst die met In-Memory OLTP kan worden behaald:
Communicatie: Een toepassing die veel korte opgeslagen procedureaanroepen gebruikt, kan een kleinere prestatieverbetering opleveren in vergelijking met een toepassing met minder aanroepen en meer functionaliteit die in elke opgeslagen procedure is geïmplementeerd.
Transact-SQL uitvoering: In-Memory OLTP behaalt de beste prestaties bij het gebruik van native gecompileerde opgeslagen procedures in plaats van geïnterpreteerde opgeslagen procedures of query-uitvoering. Het kan een voordeel zijn om toegang te krijgen tot voor geheugen geoptimaliseerde tabellen vanuit dergelijke opgeslagen procedures.
Bereikscan versus puntopzoeking: Niet-geclusterde indexen die zijn geoptimaliseerd voor geheugen, ondersteunen bereikscans en geordende scans. Voor het opzoeken van punten presteren hash-indexen met geoptimaliseerd geheugen beter dan niet-geclusterde indexen die zijn geoptimaliseerd voor geheugen. Niet-geclusterde indexen die zijn geoptimaliseerd voor geheugen, presteren beter dan schijfindexen.
- Vanaf SQL Server 2016 kan het queryplan voor een tabel die is geoptimaliseerd voor geheugen de tabel parallel scannen. Dit verbetert de prestaties van analytische query's.
- Hash-indexen konden in SQL Server 2016 ook parallel worden gescand.
- Niet-geclusterde indexen kunnen ook parallel worden gescand in SQL Server 2016.
Index bewerkingen: Indexbewerkingen worden niet geregistreerd en bestaan alleen in het geheugen.
Concurrency: Toepassingen waarvan de prestaties worden beïnvloed door gelijktijdigheid op motorniveau, zoals vergrendeling of blokkering, verbeteren aanzienlijk wanneer de toepassing wordt verplaatst naar In-Memory OLTP.
In de volgende tabel vindt u een overzicht van de prestatie- en schaalbaarheidsproblemen die vaak worden aangetroffen in relationele databases en hoe In-Memory OLTP de prestaties kan verbeteren.
| Probleem | Impact van In-Memory OLTP |
|---|---|
| Prestatie Hoog gebruik van bronnen (CPU, I/O, netwerk of geheugen). |
CPU (Centrale Verwerkings Eenheid) Native gecompileerde opgeslagen procedures kunnen het CPU-gebruik aanzienlijk verlagen, omdat er minder instructies nodig zijn om een Transact-SQL instructie uit te voeren in vergelijking met geïnterpreteerde opgeslagen procedures. In-Memory OLTP kan helpen de hardware-investering in uitgeschaalde workloads te verminderen, omdat één server mogelijk de doorvoer van meerdere servers kan leveren. Invoer/Uitvoer Als u een I/O-knelpunt tegenkomt van verwerking naar gegevens- of indexpagina's, kan In-Memory OLTP het knelpunt verminderen. Bovendien is de controle van In-Memory OLTP-objecten continu en leidt dit niet tot een plotselinge toename van I/O-bewerkingen. Als de werkset van de prestatiekritieke tabellen echter niet in het geheugen past, is In-Memory OLTP niet van toepassing omdat de gegevens in het geheugen moeten staan. Als u een I/O-knelpunt tegenkomt bij het loggen, kan In-Memory OLTP het knelpunt verkleinen omdat er minder wordt gelogd. Als een of meer tabellen met geoptimaliseerd geheugen zijn geconfigureerd als niet-duurzame tabellen, kunt u logboekregistratie voor gegevens elimineren. Geheugen In-Memory OLTP biedt geen enkel prestatievoordeel. In-Memory OLTP kan extra druk uitoefenen op het geheugen omdat de objecten in het geheugen moeten wonen. Netwerk In-Memory OLTP biedt geen enkel prestatievoordeel. De gegevens moeten worden gecommuniceerd van gegevenslaag naar toepassingslaag. |
| Schaalbaarheid De meeste schaalproblemen in SQL Server-toepassingen worden veroorzaakt door gelijktijdigheidsproblemen, zoals conflicten in sloten, vergrendelingen en spinlocks. |
Latch-contentie Een typisch scenario is onenigheid op de laatste pagina van een index bij het gelijktijdig invoegen van rijen in sleutelvolgorde. Omdat In-Memory OLTP geen vergrendelingen gebruikt bij het openen van gegevens, worden de schaalbaarheidsproblemen met betrekking tot vergrendelingsgeschillen volledig verwijderd. Spinlock Strijd Omdat In-Memory OLTP geen vergrendelingen gebruikt bij het openen van gegevens, worden de schaalbaarheidsproblemen met betrekking tot spinlock-geschillen volledig verwijderd. Vergrendeling gerelateerde bewering Als uw databasetoepassing blokkeringsproblemen ondervindt tussen lees- en schrijfbewerkingen, verwijdert In-Memory OLTP de blokkeringsproblemen omdat een nieuwe vorm van optimistische gelijktijdigheidscontrole wordt gebruikt om alle transactie-isolatieniveaus te implementeren. In-Memory OLTP gebruikt TempDB niet om rijversies op te slaan. Als het schaalprobleem wordt veroorzaakt door een conflict tussen twee schrijfbewerkingen, zoals twee gelijktijdige transacties die dezelfde rij proberen bij te werken, laat In-Memory OLTP de ene transactie slagen en mislukt de andere transactie. De mislukte transactie moet expliciet of impliciet opnieuw worden ingediend, waarbij de transactie opnieuw wordt geprobeerd. In beide gevallen moet u wijzigingen aanbrengen in de toepassing. Als uw toepassing vaak conflicten ondervindt tussen twee schrijfbewerkingen, wordt de waarde van optimistische vergrendeling verminderd. De applicatie is niet geschikt voor In-Memory OLTP. De meeste OLTP-applicaties hebben geen schrijfconflicten, tenzij het conflict het gevolg is van escalatie van vergrendelingen. |
Beveiliging op rijniveau in geheugen-geoptimaliseerde tabellen
Row-Level Security wordt ondersteund in tabellen die zijn geoptimaliseerd voor geheugen. Het toepassen van Row-Level beveiligingsbeleid op tabellen die zijn geoptimaliseerd voor geheugen is in wezen hetzelfde als op schijf gebaseerde tabellen, behalve dat de inline tabelwaarden die als beveiligingspredicaten worden gebruikt, systeemeigen moeten worden gecompileerd (gemaakt met de optie MET NATIVE_COMPILATION). Zie de sectie Compatibiliteit tussen functies in het onderwerp Row-Level Beveiliging voor meer informatie.
Er zijn verschillende ingebouwde beveiligingsfuncties beschikbaar die essentieel zijn voor beveiliging op rijniveau, voor tabellen die zijn geoptimaliseerd voor geheugen. Zie Ingebouwde functies in systeemeigen gecompileerde modules voor meer informatie.
EXECUTE AS CALLER - Alle systeemeigen modules ondersteunen en gebruiken EXECUTE AS nu AANROEPER standaard, zelfs als de hint niet is opgegeven. Dit komt omdat wordt verwacht dat alle beveiligingspredicaatfuncties op rijniveau CALLER gebruiken EXECUTE AS , zodat de functie, en alle ingebouwde functies die erin worden gebruikt, worden geëvalueerd in de context van de aanroepende gebruiker.
EXECUTE AS CALLER heeft een klein prestatieverlies (ongeveer 10%) als gevolg van machtigingscontroles voor de aanroeper. Als de module expliciet EXECUTE AS OWNER of EXECUTE AS SELF specificeert, worden deze machtigingscontroles en de bijbehorende prestatiekosten voorkomen. Het gebruik van een van deze opties in combinatie met de genoemde ingebouwde functies leidt echter tot een hogere prestatiehit vanwege de noodzakelijke contextwisseling.
Scenariën
Zie In-Memory OLTP voor een korte bespreking van typische scenario's waarin In-Memory OLTP de prestaties kan verbeteren.