Delen via

Plan uw acceptatie van In-Memory OLTP-functies in SQL Server

  • Artikel

van toepassing op:SQL ServerAzure SQL DatabaseAzure SQL Managed Instance

In dit artikel worden de manieren beschreven waarop de acceptatie van in-memory functies in SQL Server van invloed is op andere aspecten van uw bedrijfssysteem.

Notitie

Een. Acceptatie van In-Memory OLTP-functies

In de volgende subsecties worden factoren besproken die u moet overwegen wanneer u van plan bent In-Memory functies te implementeren.

A.1-vereisten

Een vereiste voor het gebruik van de In-Memory-functies kan betrekking hebben op de editie of servicelaag van het SQL-product. Zie voor deze en andere vereisten:

A.2 De hoeveelheid actief geheugen voorspellen

Beschikt uw systeem over voldoende actief geheugen ter ondersteuning van een nieuwe tabel die is geoptimaliseerd voor geheugen?

Microsoft SQL Server

Voor een tabel die is geoptimaliseerd voor geheugen die 200 GB aan gegevens bevat, is meer dan 200 GB actief geheugen vereist voor ondersteuning. Voordat u een tabel implementeert die is geoptimaliseerd voor geheugen met een grote hoeveelheid gegevens, moet u de hoeveelheid extra actief geheugen voorspellen die u mogelijk moet toevoegen aan uw servercomputer. Zie voor schattingsrichtlijnen:

Vergelijkbare richtlijnen zijn beschikbaar voor Azure SQL Managed Instance:

Azure SQL Database

Voor een database die wordt gehost in de Azure SQL Database-cloudservice, is de gekozen servicelaag van invloed op de hoeveelheid actief geheugen die uw database mag gebruiken. U moet het geheugengebruik van uw database controleren met behulp van een waarschuwing. Zie voor meer informatie:

Tabelvariabelen die zijn geoptimaliseerd voor geheugen

Een tabelvariabele die is gedeclareerd als geoptimaliseerd geheugen, is soms te verkiezen boven een traditionele #TempTable die zich in de tempdb database bevindt. Tabelvariabelen kunnen prestatieverbeteringen bieden zonder aanzienlijke hoeveelheden actief geheugen te gebruiken.

A.3-tabel moet offline zijn om te worden omgezet naar geheugen-geoptimaliseerd

Sommige ALTER TABLE-functionaliteit is beschikbaar voor tabellen die zijn geoptimaliseerd voor geheugen. U kunt echter geen ALTER TABLE-instructie geven om een tabel op basis van schijf te converteren naar een tabel die is geoptimaliseerd voor geheugen. In plaats daarvan moet u een meer handmatige set stappen gebruiken. Hier volgen verschillende manieren waarop u uw op schijf gebaseerde tabel kunt converteren naar een voor het geheugen geoptimaliseerde tabel.

Handmatige scripting

Een manier om uw schijftabel te converteren naar een tabel die is geoptimaliseerd voor geheugen, is door de benodigde Transact-SQL stappen zelf te codeeren.

  1. Toepassingsactiviteit onderbreken.

  2. Maak een volledige back-up.

  3. Wijzig de naam van de tabel op basis van de schijf.

  4. Geef een CREATE TABLE-instructie uit om uw nieuwe tabel te maken die is geoptimaliseerd voor geheugen.

  5. Voeg in je geheugen-geoptimaliseerde tabel een sub-SELECT in vanuit de schijf-gebaseerde tabel.

  6. Verwijder uw op schijf gebaseerde tabel.

  7. Maak nog een volledige back-up.

  8. Toepassingsactiviteit hervatten.

Advisor voor geheugenoptimalisatie

Het hulpprogramma Memory Optimization Advisor kan een script genereren om de conversie van een schijftabel naar een tabel die is geoptimaliseerd voor geheugen te implementeren. Het hulpprogramma wordt geïnstalleerd als onderdeel van SQL Server Data Tools (SSDT).

.dacpac-bestand

U kunt uw database in-place bijwerken met behulp van een DACPAC-bestand dat wordt beheerd door SSDT. In SSDT kunt u wijzigingen opgeven in het schema dat is gecodeerd in het DACPAC-bestand.

U werkt met DACPAC-bestanden in de context van een Visual Studio-project van het type Database.

A.4 Richtlijnen voor het feit of In-Memory OLTP-functies geschikt zijn voor uw toepassing

Zie voor meer informatie over of In-Memory OLTP-functies de prestaties van uw specifieke toepassing kunnen verbeteren:

B. Niet-ondersteunde functies

Functies die niet worden ondersteund in bepaalde In-Memory OLTP-scenario's worden beschreven op:

In de volgende subsecties worden enkele van de belangrijkste niet-ondersteunde functies gemarkeerd.

B.1 MOMENTOPNAME van een database

Na de eerste keer dat een geheugen-geoptimaliseerde tabel of module in een bepaalde database is gemaakt, kan er nooit een SNAPSHOT- van de database worden gemaakt. De specifieke reden is dat:

  • Het eerste voor geheugen geoptimaliseerde item maakt het onmogelijk om het laatste bestand ooit te verwijderen uit de door het geheugen geoptimaliseerde FILEGROUP; en
  • Geen enkele database die een bestand in een met geheugen geoptimaliseerde FILEGROUP heeft, kan een MOMENTOPNAME ondersteunen.

Normaal gesproken kan een MOMENTOPNAME handig zijn voor snelle testiteraties.

B.2 Databaseoverschrijdende query's

Tabellen die zijn geoptimaliseerd voor geheugen bieden geen ondersteuning voor transacties voor meerdere databases. U hebt geen toegang tot een andere database vanuit dezelfde transactie of dezelfde query die ook toegang heeft tot een tabel die is geoptimaliseerd voor geheugen.

Tabelvariabelen zijn niet transactioneel. Daarom kunnen tabelvariabelen die zijn geoptimaliseerd voor geheugen worden gebruikt in query's voor meerdere databases.

B.3 HINT VOOR READPAST-tabel

Geen enkele query kan de hint READPAST op een tabel toepassen die geoptimaliseerd is voor geheugen.

De READPAST-hint is handig in scenario's waarin verschillende sessies ieder eenzelfde kleine set rijen openen en wijzigen, zoals bij het verwerken van een wachtrij.

B.4 RowVersion, Volgorde

  • Er kan geen kolom worden gelabeld voor RowVersion- in een tabel die is geoptimaliseerd voor geheugen.

  • Een SEQUENCE- kan niet worden gebruikt met een beperking in een tabel die is geoptimaliseerd voor geheugen. U kunt bijvoorbeeld geen standaardbeperking maken met een NEXT VALUE FOR-clausule. SEQUENCEs kunnen worden gebruikt met INSERT- en UPDATE-instructies.

C. Beheeronderhoud

In deze sectie worden verschillen in databasebeheer beschreven waarbij tabellen die zijn geoptimaliseerd voor geheugen worden gebruikt.

C.1 Identity seed reset, increment > 1

DBCC CHECKIDENT, om een IDENTITY-kolom opnieuw te zaaien, kan niet worden gebruikt voor een tabel die is geoptimaliseerd voor geheugen.

De incrementele waarde is beperkt tot exact 1 voor een IDENTITY-kolom in een tabel die is geoptimaliseerd voor geheugen.

C.2 DBCC CHECKDB kan tabellen die zijn geoptimaliseerd voor geheugen niet valideren

De opdracht DBCC CHECKDB doet niets wanneer het doel een tabel is die is geoptimaliseerd voor geheugen. De volgende stappen zijn een tijdelijke oplossing:

  1. een back-up maken van het transactielogboek.

  2. Maak een back-up van de bestanden in de voor geheugen geoptimaliseerde FILEGROUP naar een null-apparaat. Het back-upproces roept een controlesomvalidatie aan.

    Als er corruptie wordt gevonden, gaat u verder met de volgende stappen.

  3. Kopieer gegevens uit uw tabellen die zijn geoptimaliseerd voor geheugen naar schijftabellen voor tijdelijke opslag.

  4. Herstel de bestanden van de voor geheugen geoptimaliseerde FILEGROUP.

  5. Voer de gegevens die u tijdelijk in de schijfgebaseerde tabellen hebt opgeslagen in de geheugen-geoptimaliseerde tabellen in.

  6. Verwijder de schijfgebaseerde tabellen die tijdelijk de gegevens bevatten.

D. Prestatie

In deze sectie worden situaties beschreven waarin de uitstekende prestaties van tabellen die zijn geoptimaliseerd voor geheugen, onder het volledige potentieel kunnen worden gehouden.

Overwegingen voor D.1-index

Alle indexen in een tabel die is geoptimaliseerd voor geheugen worden gemaakt en beheerd door de tabelgerelateerde instructies CREATE TABLE en ALTER TABLE. U kunt geen geheugen-geoptimaliseerde tabel targeten met een CREATE INDEX-instructie.

De traditionele B-tree niet-geclusterde index is vaak de verstandige en eenvoudige keuze wanneer u voor het eerst een tabel implementeert die is geoptimaliseerd voor geheugen. Nadat u later hebt gezien hoe uw toepassing presteert, kunt u overwegen een ander indextype te wisselen.

Notitie

Documentatie maakt gebruik van de term B-tree in het algemeen in verwijzing naar indexen. In rowstore-indexen implementeert de database-engine een B+-boom. Dit geldt niet voor columnstore-indexen of indexen voor tabellen die zijn geoptimaliseerd voor geheugen. Zie de SQL Server- en Azure SQL-indexarchitectuur en ontwerphandleidingvoor meer informatie.

Twee speciale typen indexen moeten worden besproken in de context van een tabel die is geoptimaliseerd voor geheugen: Hash-indexen en Columnstore-indexen.

Zie voor een overzicht van indexen voor tabellen die zijn geoptimaliseerd voor geheugen:

Hash-indexen

Hash-indexen kunnen de snelste indeling zijn voor toegang tot één specifieke rij met de exacte primaire-sleutelwaarde met behulp van de operator '='.

  • Inexact-operators zoals '!=', '>' of 'BETWEEN' zouden de prestaties schaden als deze worden gebruikt met een hash-index.

  • Een hash-index is mogelijk niet de beste keuze als de snelheid van sleutelwaardeduplicatie te hoog wordt.

  • Waak ervoor dat u niet onderschat hoeveel buckets uw hash-index mogelijk nodig heeft, om lange ketens binnen individuele buckets te vermijden. Zie voor meer informatie:

Niet-geclusterde columnstore-indexen

Tabellen die zijn geoptimaliseerd voor geheugen leveren een hoge doorvoer van typische zakelijke transactionele gegevens. In het paradigma noemen we online transactieverwerking of OLTP-. Columnstore-indexen bieden een hoge doorvoer bij aggregaties en vergelijkbare verwerking die we Analyticsnoemen. In het verleden was de beste aanpak die beschikbaar was om te voldoen aan de behoeften van zowel OLTP als Analytics, afzonderlijke tabellen met een zware verplaatsing van gegevens en met een zekere mate van gegevensduplicatie. Tegenwoordig is een eenvoudigere hybride oplossing beschikbaar: een columnstore-index hebben voor een tabel die is geoptimaliseerd voor geheugen.

  • Een columnstore index kan worden gebouwd op een schijfgebaseerde tabel, zelfs als de gegroepeerde index. Maar in een tabel die is geoptimaliseerd voor geheugen, kan een columnstore-index niet worden geclusterd.

  • LOB- of buiten-de-rij-kolommen voor een geheugen-geoptimaliseerde tabel verhinderen de creatie van een columnstore-index op de tabel.

  • Er kan geen ALTER TABLE-instructie worden uitgevoerd voor een tabel die is geoptimaliseerd voor geheugen, terwijl er een columnstore-index in de tabel bestaat.

    • Vanaf augustus 2016 heeft Microsoft plannen op korte termijn om de prestaties van het opnieuw maken van de columnstore-index te verbeteren.

D.2 LOB- en buitenrij-kolommen

Grote objecten (LOBs) zijn kolommen van bijvoorbeeld varchar(max). Het hebben van een aantal LOB-kolommen in een tabel die is geoptimaliseerd voor geheugen, heeft waarschijnlijk geen gevolgen voor de prestaties. Maar vermijd dat u meer LOB-kolommen hebt dan uw gegevens nodig hebben. Hetzelfde advies is van toepassing op kolommen buiten de rij. Definieer geen kolom als nvarchar(3072) als varchar(512) voldoende is.

Meer informatie over LOB- en off-row-kolommen vindt u op:

E. Beperkingen van ingebouwde procs

Bepaalde elementen van Transact-SQL worden niet ondersteund in systeemeigen gecompileerde T-SQL-modules, waaronder opgeslagen procedures. Zie voor meer informatie over welke functies worden ondersteund:

Voor overwegingen bij het migreren van een Transact-SQL-module die gebruikmaakt van niet-ondersteunde functies die systeemeigen moeten worden gecompileerd, raadpleegt u:

Naast beperkingen voor bepaalde elementen van Transact-SQL zijn er ook beperkingen voor queryoperators die worden ondersteund in systeemeigen gecompileerde T-SQL-modules. Vanwege deze beperkingen zijn systeemeigen gecompileerde opgeslagen procedures niet geschikt voor analytische query's die grote gegevenssets verwerken.

Geen parallelle verwerking in een systeemeigen proc

Parallelle verwerking kan geen deel uitmaken van een queryplan voor een systeemeigen proc. Systeemeigen procs zijn altijd single-threaded.

Verbindingstypen

Zowel hash-joins als samenvoegingsdeelnames kunnen geen deel uitmaken van een queryplan voor een systeemeigen proc. Geneste loopjoins worden gebruikt.

Geen hash-aggregatie

Wanneer voor het queryplan voor een systeemeigen proc een aggregatiefase is vereist, is alleen stroomaggregatie beschikbaar. Hash-aggregatie wordt niet ondersteund in een queryplan voor een systeemeigen proc.

  • Hashaggregatie is beter wanneer gegevens uit een groot aantal rijen moeten worden geaggregeerd.

F. Toepassingsontwerp: Transacties en logica voor opnieuw proberen

Een transactie met een tabel die is geoptimaliseerd voor geheugen, kan afhankelijk worden van een andere transactie die dezelfde tabel omvat. Als het aantal afhankelijke transacties het toegestane maximum bereikt, mislukken alle afhankelijke transacties.

In SQL Server 2016:

  • Het toegestane maximum is acht afhankelijke transacties. Acht is ook de limiet van transacties waarvan een bepaalde transactie afhankelijk kan zijn.
  • Het foutnummer is 41839. (In SQL Server 2014 is het foutnummer 41301.)

U kunt uw Transact-SQL scripts robuuster maken tegen een mogelijke transactiefout door logica voor het herhalen van pogingen toe te voegen aan uw scripts. Logica voor opnieuw proberen is waarschijnlijk handiger wanneer update- en DELETE-aanroepen regelmatig worden uitgevoerd, of als naar de voor geheugen geoptimaliseerde tabel wordt verwezen door een refererende sleutel in een andere tabel. Zie voor meer informatie:

Verwante inhoud