Anteckning
Åtkomst till den här sidan kräver auktorisering. Du kan prova att logga in eller ändra kataloger.
Åtkomst till den här sidan kräver auktorisering. Du kan prova att ändra kataloger.
Gäller för:
SQL ServerAzure SQL DatabaseAzure SQL Managed Instance
Minnesoptimerade tabeller skapas med create table (Transact-SQL).
Minnesoptimerade tabeller är helt hållbara som standard, och precis som transaktioner på (traditionella) diskbaserade tabeller är transaktioner på minnesoptimerade tabeller helt atomiska, konsekventa, isolerade och hållbara (ACID). Minnesoptimerade tabeller och inbyggda kompilerade lagrade procedurer stöder endast en delmängd av Transact-SQL funktioner.
Från och med SQL Server 2016 och i Azure SQL Database finns det inga begränsningar för kollationeringar eller kodsidor som är specifika för In-Memory OLTP.
Det primära lagringsutrymmet för minnesoptimerade tabeller är huvudminnet. Rader i tabellen läss från och skrivs till minnet. En andra kopia av tabelldata underhålls på disken, men endast i hållbarhetssyfte. Mer information om varaktiga tabeller finns i Skapa och hantera lagring för Memory-Optimized objekt . Data i minnesoptimerade tabeller skrivs bara från disken under databasåterställning (till exempel efter en omstart av servern).
För ännu större prestandavinster stöder In-Memory OLTP hållbara tabeller med fördröjd transaktionshållbarhet. Fördröjda varaktiga transaktioner sparas på disken strax efter att transaktionen checkats in och kontrollen returneras till klienten. I utbyte mot den ökade prestandan går bekräftade transaktioner som inte sparas på disk förlorade vid en serverkrasch eller övergång till reservsystem.
Förutom de förvalda hållbara minnesoptimerade tabellerna stöder SQL Server även icke-hållbara minnesoptimerade tabeller, som inte loggas och deras data inte sparas på disken. Det innebär att transaktioner i dessa tabeller inte kräver någon disk-I/O, men data går förlorade om det uppstår en serverkrasch eller redundansväxling.
In-Memory OLTP är integrerat med SQL Server för att ge en smidig upplevelse inom alla områden som utveckling, distribution, hanterbarhet och support. En databas kan innehålla både minnesintern och diskbaserade objekt.
Rader i minnesoptimerade tabeller är versionerade. Det innebär att varje rad i tabellen potentiellt har flera versioner. Alla radversioner underhålls i samma tabelldatastruktur. Radversionshantering används för att tillåta samtidiga läsningar och skrivningar på samma rad. Mer information om samtidiga läsningar och skrivningar på samma rad finns i Transaktioner med Memory-Optimized tabeller.
Följande bild illustrerar multiversionshantering. Bilden visar en tabell med tre rader och varje rad har olika versioner.
Tabellen har tre rader: r1, r2 och r3. r1 har tre versioner, r2 har två versioner och r3 har fyra versioner. Olika versioner av samma rad behöver inte nödvändigtvis ligga på minnesplatser som följer varandra. De olika radversionerna kan spridas i tabelldatastrukturen.
Den minnesoptimerade tabelldatastrukturen kan ses som en samling radversioner. Rader i diskbaserade tabeller ordnas i sidor och omfattningar, och de enskilda raderna adresseras med sidnummer och sidförskjutning. Radversioner i minnesoptimerade tabeller adresseras med hjälp av 8-byte minnespekare.
Data i minnesoptimerade tabeller nås på två sätt:
Genom naturligt kompilerade lagrade procedurer.
Via tolkad Transact-SQL, utanför en inbyggt kompilerad lagrad procedur. Dessa Transact-SQL-instruktioner kan antingen finnas i tolkade lagrade procedurer eller vara ad hoc-Transact-SQL-instruktioner.
Komma åt data i Memory-Optimized tabeller
Minnesoptimerade tabeller kan nås mest effektivt från inbyggda kompilerade lagrade procedurer (internt kompilerade lagrade procedurer). Minnesoptimerade tabeller kan också nås med (traditionell) tolkad Transact-SQL. Tolkade Transact-SQL avser åtkomst till minnesoptimerade tabeller utan en inbyggt kompilerad lagrad procedur. Några exempel på tolkad Transact-SQL-åtkomst är att komma åt en minnesoptimerad tabell från en DML-utlösare, en ad hoc Transact-SQL-batch, vy och tabellvärdesfunktion.
I följande tabell sammanfattas intern och tolkad Transact-SQL åtkomst för olika objekt.
| Egenskap | Åtkomst med hjälp av en nativt kompilerad lagrad procedur | Tolkad Transact-SQL Access | CLR-åtkomst |
|---|---|---|---|
| Minnesoptimerad tabell | Ja | Ja | Nr1 |
| Minnesoptimerad tabelltyp | Ja | Ja | Nej |
| Inbyggt kompilerad lagrad procedur | Kapsling av inbyggda kompilerade lagrade procedurer stöds nu. Du kan använda EXECUTE-syntaxen i de lagrade procedurerna, så länge den refererade proceduren också kompileras internt. | Ja | Nej* |
1Du kan inte komma åt en minnesoptimerad tabell eller internt kompilerad lagrad procedur från kontextanslutningen (anslutningen från SQL Server när du kör en CLR-modul). Du kan dock skapa och öppna en annan anslutning från vilken du kan komma åt minnesoptimerade tabeller och internt kompilerade lagrade procedurer.
Känsliga data i minnesoptimerade tabeller kan skyddas med Always Encrypted. Följande begränsningar gäller:
- När du använder Always Encrypted med säkra enklaver stöds inte användning av enklaveraktiverade nycklar för kolumner i minnesoptimerade tabeller. Det innebär att kryptering på plats inte kan användas och att den första krypteringen görs på klienten.
- Always Encrypted stöds inte för någon kolumn i en minnesoptimerad tabell när tabellen refereras till i en inbyggt kompilerad modul.
Prestanda och skalbarhet
Följande faktorer påverkar de prestandavinster som kan uppnås med In-Memory OLTP:
Kommunikation: Ett program som använder många korta lagrade proceduranrop kan se en mindre prestandavinst jämfört med ett program med färre anrop och fler funktioner som implementeras i varje lagrad procedur.
Transact-SQL Exekvering: In-Memory OLTP uppnår bästa prestanda när man använder inbyggda kompilerade lagrade procedurer i stället för tolkade lagrade procedurer eller frågeexekvering. Det kan finnas en fördel med att komma åt minnesoptimerade tabeller från sådana lagrade procedurer.
Intervallgenomsökning jämfört med punktsökning: Minnesoptimerade icke-grupperade index stöder intervallgenomsökningar och ordnade genomsökningar. För punktsökningar har minnesoptimerade hash-index bättre prestanda än minnesoptimerade icke-lustererade index. Minnesoptimerade icke-grupperade index har bättre prestanda än diskbaserade index.
- Från och med SQL Server 2016 kan frågeplanen för en minnesoptimerad tabell söka igenom tabellen parallellt. Detta förbättrar prestandan för analysfrågor.
- Hash-index kunde också skannas parallellt i SQL Server 2016.
- Icke-grupperade index kan också skannas parallellt i SQL Server 2016.
Indexåtgärder: Indexåtgärder loggas inte och de finns bara i minnet.
Samtidighet: Program vars prestanda påverkas av samtidighet på motornivå, till exempel spärrkonkurrens eller blockering, förbättras avsevärt när programmet flyttas till In-Memory OLTP.
I följande tabell visas prestanda- och skalbarhetsproblem som ofta finns i relationsdatabaser och hur In-Memory OLTP kan förbättra prestandan.
| Problematik | In-Memory OLTP-effekt |
|---|---|
| Prestanda Hög resursanvändning (CPU, I/O, nätverk eller minne). |
CPU (centralenhet) Internt kompilerade lagrade procedurer kan minska CPU-användningen avsevärt eftersom de kräver färre instruktioner för att köra en Transact-SQL-instruktion jämfört med tolkade lagrade procedurer. In-Memory OLTP kan bidra till att minska maskinvaruinvesteringen i utskalade arbetsbelastningar eftersom en server potentiellt kan leverera dataflödet för flera servrar. I/O Om du stöter på en I/O-flaskhals vid bearbetning av data- eller indexsidor kan In-Memory OLTP minska flaskhalsen. Dessutom är kontrollpunkterna för In-Memory OLTP-objekt kontinuerliga och leder inte till plötsliga ökningar av I/O-åtgärder. Men om arbetsuppsättningen för de prestandakritiska tabellerna inte passar i minnet gäller inte In-Memory OLTP eftersom det kräver att data är minnesboende. Om du stöter på en I/O-flaskhals i loggningen kan In-Memory OLTP minska flaskhalsen eftersom den gör mindre loggning. Om en eller flera minnesoptimerade tabeller har konfigurerats som icke-varaktiga tabeller kan du eliminera loggning för data. Minne In-Memory OLTP erbjuder ingen prestandaförmån. In-Memory OLTP kan sätta extra press på minnet eftersom objekten måste vara minnesboende. Nätverk In-Memory OLTP erbjuder ingen prestandaförmån. Data måste kommuniceras från datanivå till programnivå. |
| Skalbarhet De flesta skalningsproblem i SQL Server-program orsakas av samtidighetsproblem som konkurrens i lås, spärrar och spinlocks. |
Spärrkonflikt Ett typiskt scenario är konkurrens på den sista sidan i ett index när rader infogas samtidigt i nyckelordning. Eftersom In-Memory OLTP inte tar låsförfrågningar vid åtkomst till data, tas skalbarhetsproblemen som rör låskonflikter bort helt. Spinlock-konkurrens Eftersom In-Memory OLTP inte tar lås vid åtkomst till data, tas skalbarhetsproblemen som rör spinlockkonkurrens bort helt. Låsningsrelaterad konflikt Om ditt databasprogram stöter på blockeringsproblem mellan läs- och skrivåtgärder tar In-Memory OLTP bort blockeringsproblemen eftersom det använder en ny form av optimistisk samtidighetskontroll för att implementera alla transaktionsisoleringsnivåer. In-Memory OLTP använder inte TempDB för att lagra radversioner. Om skalningsproblemet orsakas av en konflikt mellan två skrivåtgärder, till exempel två samtidiga transaktioner som försöker uppdatera samma rad, låter In-Memory OLTP en transaktion lyckas och misslyckas med den andra transaktionen. Den misslyckade transaktionen måste skickas på nytt, antingen explicit eller implicit, genom att försöka igen med transaktionen. I båda fallen måste du göra ändringar i programmet. Om din applikation ofta upplever konflikter mellan två skrivåtgärder försämras värdet av optimistisk låsning. Programmet är inte lämpligt för In-Memory OLTP. De flesta OLTP-program har inte skrivkonflikter om inte konflikten beror på låseskalering. |
Row-Level säkerhet i Memory-Optimized tabeller
Row-Level Säkerhet stöds i minnesoptimerade tabeller. Att tillämpa Row-Level säkerhetsprinciper på minnesoptimerade tabeller är i stort sett detsamma som diskbaserade tabeller, förutom att de infogade tabellvärdesfunktioner som används som säkerhetspredikat måste kompileras internt (skapas med alternativet WITH NATIVE_COMPILATION). Mer information finns i avsnittet Kompatibilitet mellan funktioner i avsnittet Row-Level Säkerhet .
Olika inbyggda säkerhetsfunktioner som är viktiga för säkerhet på radnivå är tillgängliga för minnesoptimerade tabeller. Mer information finns i Inbyggda funktioner i inbyggda kompilerade moduler.
EXECUTE AS CALLER – Alla inbyggda moduler stöder nu och använder EXECUTE AS CALLER som standard, även om tipset inte har angetts. Detta beror på att det förväntas att alla säkerhetspredikatfunktioner på radnivå använder EXECUTE AS CALLER så att funktionen och alla inbyggda funktioner som används i den utvärderas i kontexten för den anropande användaren.
EXECUTE AS CALLER har en liten (ungefär 10%) prestandapåverkan orsakad av behörighetskontroller på anroparen. Om modulen uttryckligen anger KÖR SOM ÄGARE eller KÖR SOM SJÄLV, undviks dessa behörighetskontroller och deras associerade prestandakostnad. Om du använder något av de här alternativen tillsammans med de inbyggda funktionerna får du dock högre prestanda på grund av den nödvändiga kontextväxlingen.
Scenarier
En kort beskrivning av vanliga scenarier där In-Memory OLTP kan förbättra prestanda finns iIn-Memory OLTP.