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 behulp van CREATE TABLE (Transact-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 gelezen en in het geheugen geschreven. Een tweede kopie van de tabelgegevens wordt op schijf bewaard, maar alleen voor duurzaamheidsdoeleinden. Zie Opslag maken en beheren voor Memory-Optimized objecten voor meer informatie over duurzame tafels. 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 Memory-Optimized 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:
Door middel van native gecompileerde opgeslagen procedures.
Via geïnterpreteerde Transact-SQL, buiten een native gecompileerde opgeslagen 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
Tabellen die zijn geoptimaliseerd voor geheugen, kunnen het meest efficiënt worden geopend vanuit native gecompileerde opgeslagen procedures (native 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 met behulp van een native gecompileerde opgeslagen procedure | Geïnterpreteerd Transact-SQL Access | CLR-toegang |
|---|---|---|---|
| Tabel geoptimaliseerd voor geheugen | Ja | Ja | Nr.1 |
| Tabeltype dat is geoptimaliseerd voor geheugen | Ja | Ja | Nee. |
| Native gecompileerde opgeslagen procedure | Het nesten van native 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 werden ook scanbaar in parallel in SQL Server 2016.
- 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 | In-Memory OLTP-impact |
|---|---|
| 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. |
Vergrendeling Twist 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. |
Row-Level Veiligheid in Memory-Optimized Tafels
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.
UITVOEREN ALS AANROEPER - Alle native modules ondersteunen en gebruiken nu standaard UITVOEREN ALS AANROEPER, zelfs als de hint niet is opgegeven. Dit komt omdat wordt verwacht dat alle beveiligingspredicaatfuncties op rijniveau EXECUTE AS CALLER gebruiken, zodat de functie en eventuele ingebouwde functies die erin worden gebruikt, worden geëvalueerd in de context van de aanroepende gebruiker.
EXECUTE AS CALLER heeft een kleine (ongeveer 10%) prestatiehit veroorzaakt door toestemmingscontroles op de beller. Als de module expliciet UITVOEREN ALS EIGENAAR of UITVOEREN ALS ZELF specificeert, worden deze machtigingscontroles en de bijbehorende prestatiekosten vermeden. 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.