Dela via

Planera införandet av In-Memory OLTP-funktioner i SQL Server

  • Artikel

gäller för:SQL ServerAzure SQL DatabaseAzure SQL Managed Instance

Den här artikeln beskriver hur införandet av minnesinterna funktioner i SQL Server påverkar andra aspekter av ditt affärssystem.

Not

A. Införande av In-Memory OLTP-funktioner

Följande underavsnitt beskriver faktorer som du måste tänka på när du planerar att införa och implementera In-Memory funktioner.

A.1 Förutsättningar

En förutsättning för att använda In-Memory funktioner kan omfatta sql-produktens utgåva eller tjänstnivå. För detta och andra krav, se:

A.2 Prognostisera mängden aktivt minne

Har systemet tillräckligt med aktivt minne för att stödja en ny minnesoptimerad tabell?

Microsoft SQL Server

En minnesoptimerad tabell som innehåller 200 GB data kräver att mer än 200 GB aktivt minne är dedikerat till dess stöd. Innan du implementerar en minnesoptimerad tabell som innehåller en stor mängd data måste du förutse mängden ytterligare aktivt minne som du kan behöva lägga till på serverdatorn. Information om uppskattning finns i:

Liknande vägledning finns för Azure SQL Managed Instance:

Azure SQL Database

För en databas som finns i Azure SQL Database-molntjänsten påverkar den valda tjänstnivån mängden aktivt minne som databasen tillåts använda. Du bör planera att övervaka minnesanvändningen för databasen med hjälp av en avisering. Mer information finns i:

Minnesoptimerade tabellvariabler

En tabellvariabel som deklareras vara minnesoptimerad är ibland att föredra framför en traditionell #TempTable som finns i tempdb-databasen. Tabellvariabler kan ge prestandavinster utan att använda stora mängder aktivt minne.

A.3-tabellen måste vara offline för att konvertera till minnesoptimerad

Vissa ALTER TABLE-funktioner är tillgängliga för minnesoptimerade tabeller. Men du kan inte utfärda en ALTER TABLE-instruktion för att konvertera en diskbaserad tabell till en minnesoptimerad tabell. I stället måste du använda en mer manuell uppsättning steg. Följande är olika sätt att konvertera din diskbaserade tabell till minnesoptimerad.

Manuell skriptning

Ett sätt att konvertera din diskbaserade tabell till en minnesoptimerad tabell är att koda nödvändiga Transact-SQL steg själv.

  1. Pausa programaktiviteten.

  2. Ta en fullständig säkerhetskopia.

  3. Byt namn på den diskbaserade tabellen.

  4. Utfärda en CREATE TABLE-instruktion för att skapa den nya minnesoptimerade tabellen.

  5. INFOGA I din minnesoptimerade tabell med en under-SELECT från den diskbaserade tabellen.

  6. SLÄPP din diskbaserade tabell.

  7. Ta en ny fullständig säkerhetskopia.

  8. Återuppta programaktiviteten.

Rådgivare för minnesoptimering

Verktyget Memory Optimization Advisor kan generera ett skript för att implementera konverteringen av en diskbaserad tabell till en minnesoptimerad tabell. Verktyget installeras som en del av SQL Server Data Tools (SSDT).

.dacpac-fil

Du kan uppdatera databasen på plats med hjälp av en .dacpac-fil som hanteras av SSDT. I SSDT kan du ange ändringar i schemat som är kodat i .dacpac-filen.

Du arbetar med .dacpac-filer i kontexten för ett Visual Studio-projekt av typen Database.

A.4 Vägledning för om In-Memory OLTP-funktioner är rätt för ditt program

Information om huruvida In-Memory OLTP-funktioner kan förbättra prestanda för ditt specifika program finns i:

B. Funktioner som inte stöds

Funktioner som inte stöds i vissa In-Memory OLTP-scenarier beskrivs på:

Följande underavsnitt belyser några av de viktigaste funktionerna som inte stöds.

B.1 ÖGONBLICKSBILD av en databas

Efter första gången någon minnesoptimerad tabell eller modul skapas i en viss databas kan ingen ÖGONBLICKSBILD av databasen någonsin tas. Den specifika orsaken är att:

  • Det första minnesoptimerade objektet gör det omöjligt att någonsin släppa den sista filen från den minnesoptimerade FILEGROUP. och
  • Ingen databas som har en fil i en minnesoptimerad FILGRUPP kan stödja en ÖGONBLICKSBILD.

Normalt kan en ögonblicksbild vara praktisk för snabbtestning av iterationer.

B.2 Frågeställningar mellan databaser

Minnesoptimerade tabeller stöder inte transaktioner mellan databaser. Du kan inte komma åt en annan databas från samma transaktion eller samma fråga som också har åtkomst till en minnesoptimerad tabell.

Tabellvariabler är inte transaktionella. Därför kan minnesoptimerade tabellvariabler användas i frågor mellan databaser.

B.3 READPAST-tabellanvisning

Ingen fråga kan tillämpa READPAST-tabelltipset på en minnesoptimerad tabell.

READPAST-tipset är användbart i scenarier där flera sessioner var och en kommer åt och ändrar samma lilla uppsättning rader, till exempel vid bearbetning av en kö.

B.4 RowVersion, Sekvens

  • Ingen kolumn kan taggas för RowVersion- i en minnesoptimerad tabell.

  • En SEQUENCE- kan inte användas med en begränsning i en minnesoptimerad tabell. Du kan till exempel inte skapa en STANDARD-begränsning med en NEXT VALUE FOR-sats. SEQUENCEs kan användas med INSERT- och UPDATE-instruktioner.

C. Administrativt underhåll

I det här avsnittet beskrivs skillnader i databasadministration där minnesoptimerade tabeller används.

C.1 Återställning av identitetsutsäde, öka > 1

DBCC CHECKIDENT, för att återställa en identitetskolumn, kan inte användas i en minnesoptimerad tabell.

Inkrementsvärdet är begränsat till exakt 1 för en identitetskolumn i en minnesoptimerad tabell.

C.2 DBCC CHECKDB kan inte verifiera minnesoptimerade tabeller

Kommandot DBCC CHECKDB gör ingenting när målet är en minnesoptimerad tabell. Följande steg är en lösning:

  1. Säkerhetskopiera transaktionsloggen.

  2. Säkerhetskopiera filerna i den minnesoptimerade FILEGROUP till en null-enhet. Säkerhetskopieringsprocessen initierar en kontroll av kontrollsumman.

    Om korruption upptäcks, fortsätt med de nästa stegen.

  3. Kopiera data från dina minnesoptimerade tabeller till diskbaserade tabeller för tillfällig lagring.

  4. Återställ filerna i den minnesoptimerade FILEGROUP.

  5. INFOGA I de minnesoptimerade tabellerna de data som du tillfälligt lagrade i de diskbaserade tabellerna.

  6. SLÄPP de diskbaserade tabeller som tillfälligt innehöll data.

D. Prestanda

I det här avsnittet beskrivs situationer där den utmärkta prestandan för minnesoptimerade tabeller kan hållas under fullständig potential.

Indexöverväganden för D.1

Alla index i en minnesoptimerad tabell skapas och hanteras av tabellrelaterade instruktioner CREATE TABLE och ALTER TABLE. Du kan inte rikta in dig på en minnesoptimerad tabell med en CREATE INDEX-instruktion.

Det traditionella B-trädet icke-klustrade indexet är ofta det förnuftiga och enkla valet när du implementerar en minnesoptimerad tabell för första gången. Senare, när du ser hur programmet fungerar, kan du överväga att byta en annan indextyp.

Not

I dokumentationen används termen B-träd vanligtvis som referens till index. I radlagringsindex implementerar databasmotorn ett B+-träd. Detta gäller inte för kolumnlagringsindex eller index i minnesoptimerade tabeller. Mer information finns i arkitekturen och designguiden för SQL Server och Azure SQL-index.

Två särskilda typer av index behöver diskuteras i kontexten för en minnesoptimerad tabell: Hash-index och Columnstore-index.

En översikt över index för minnesoptimerade tabeller finns i:

Hash-indexar

Hash-index kan vara det snabbaste formatet för att komma åt en specifik rad med dess exakta primärnyckelvärde med operatorn "=".

  • Inexact-operatorer som!=,>ellerBETWEENskulle skada prestanda om de används med ett hashindex.

  • Ett hash-index kanske inte är det bästa valet om frekvensen för nyckelvärdesduplicering blir för hög.

  • Skydda dig mot att underskatta hur många bucketar ditt hashindex kan behöva för att undvika långa kedjor i enskilda bucketar. Mer information finns i:

Icke-klustrerad kolumnlagringsindex

Minnesoptimerade tabeller ger högt dataflöde för typiska affärstransaktionsdata, i det vi kallar onlinetransaktionsbearbetning eller OLTP. Kolumnlagringsindex ger högt dataflöde för aggregeringar och liknande bearbetning som vi kallar Analytics. Tidigare år var den bästa metoden för att uppfylla behoven hos både OLTP och Analytics att ha separata tabeller med tung dataförflyttning och med viss grad av dataduplicering. I dag finns det en enklare hybridlösning: ha ett kolumnlagringsindex i en minnesoptimerad tabell.

  • Ett kolumnlagringsindex kan byggas på en diskbaserad tabell, även som klustrat index. Men i en minnesoptimerad tabell går det inte att gruppera ett kolumnlagringsindex.

  • LOB- eller off-row-kolumner för en minnesoptimerad tabell förhindrar att ett kolumnlagringsindex skapas i tabellen.

  • Ingen ALTER TABLE-instruktion kan köras mot en minnesoptimerad tabell medan det finns ett kolumnlagringsindex i tabellen.

    • Från och med augusti 2016 har Microsoft kortsiktiga planer på att förbättra prestandan för återskapandet av kolumnlagringsindexet.

D.2 LOB- och off-row-kolumner

Stora objekt (LOB) är kolumner av sådana typer som varchar(max). Att ha ett par LOB-kolumner i en minnesoptimerad tabell skadar förmodligen inte prestandan tillräckligt för att spela någon roll. Men undvik att ha fler LOB-kolumner än dina databehov. Samma råd gäller för kolumner utanför rad. Definiera inte en kolumn som nvarchar(3072) om varchar(512) räcker.

Lite mer om LOB- och off-row-kolumner finns på:

E. Begränsningar för inbyggda processer

Vissa element i Transact-SQL stöds inte i internt kompilerade T-SQL-moduler, inklusive lagrade procedurer. Mer information om vilka funktioner som stöds finns i:

Överväganden vid migrering av en Transact-SQL-modul som använder funktioner som inte stöds för att kompileras nativt, se:

Förutom begränsningar för vissa element i Transact-SQL finns det även begränsningar för frågeoperatorer som stöds i inbyggda kompilerade T-SQL-moduler. På grund av dessa begränsningar är inbyggda kompilerade lagrade procedurer inte lämpliga för analysfrågor som bearbetar stora datamängder.

Ingen parallell behandling i en inbyggd process

Parallell bearbetning kan inte ingå i någon frågeplan för en intern process. Interna procs är alltid enkeltrådade.

Kopplingstyper

Både hash-kopplingar och sammanslagningskopplingar kan inte ingå i någon frågeplan för en intern process. Kapslade loopkopplingar används.

Ingen hash-sammansättning

När frågeplanen för en intern process kräver en aggregeringsfas är endast dataströmaggregering tillgänglig. Hash-aggregering stöds inte i en frågeplan för en intern process.

  • Hash-aggregering är bättre när data från ett stort antal rader måste aggregeras.

F. Programdesign: Transaktioner och logik för återförsök

En transaktion som involverar en minnesoptimerad tabell kan bli beroende av en annan transaktion som omfattar samma tabell. Om antalet beroende transaktioner når det högsta tillåtna antalet misslyckas alla beroende transaktioner.

I SQL Server 2016:

  • Det högsta tillåtna är åtta beroende transaktioner. Åtta är också gränsen för transaktioner som en viss transaktion kan vara beroende av.
  • Felnumret är 41839. (I SQL Server 2014 är felnumret 41301.)

Du kan göra dina Transact-SQL-skript mer robusta mot ett möjligt transaktionsfel genom att lägga till omförsökslogik i skripten. Återförsökslogik är mer sannolikt att vara till hjälp när UPDATE- och DELETE-anrop är frekventa, eller om den minnesoptimerade tabellen refereras av en främmande nyckel i en annan tabell. Mer information finns i:

Relaterat innehåll