Memory-Optimized tabellen wijzigen

Van toepassing op:SQL ServerAzure SQL DatabaseAzure SQL Managed Instance

Schema- en indexwijzigingen voor tabellen die zijn geoptimaliseerd voor geheugen kunnen worden uitgevoerd met behulp van de instructie ALTER TABLE. In SQL Server 2016 en Azure SQL Database, zijn de ALTER TABLE-bewerkingen voor tabellen die geoptimaliseerd zijn voor geheugen offline, wat betekent dat de tabel niet beschikbaar is voor het uitvoeren van query's terwijl de bewerking wordt uitgevoerd. De databasetoepassing kan blijven worden uitgevoerd en elke bewerking die toegang heeft tot de tabel, wordt geblokkeerd totdat het wijzigingsproces is voltooid. Het is mogelijk om meerdere bewerkingen voor toevoegen, verwijderen of wijzigen te combineren in één ALTER TABLE-instructie.

Belangrijk

Azure SQL Managed Instance biedt geen ondersteuning voor tabellen die zijn geoptimaliseerd voor geheugen in de servicelaag Algemeen gebruik.

ALTER TABLE

De syntaxis ALTER TABLE wordt gebruikt voor het aanbrengen van wijzigingen in het tabelschema, en voor het toevoegen, verwijderen en opnieuw opbouwen van indexen. Indexen worden beschouwd als onderdeel van de tabeldefinitie:

• De syntaxis ALTER TABLE ... ADD/DROP/ALTER INDEX wordt alleen ondersteund voor tabellen die zijn geoptimaliseerd voor geheugen.

• Zonder een ALTER TABLE-instructie te gebruiken, worden de instructies CREATE INDEX, DROP INDEX, ALTER INDEX en PAD_INDEX niet ondersteund voor indexen in tabellen die zijn geoptimaliseerd voor geheugen.

De volgende typen wijzigingen worden ondersteund:

• Het aantal buckets wijzigen

• Een index toevoegen en verwijderen

• Een kolom wijzigen, toevoegen en verwijderen

• Een beperking toevoegen en verwijderen

Zie ALTER TABLE (Transact-SQL) voor meer informatie over de functionaliteit ALTER TABLE en de volledige syntaxis

Schemagebonden afhankelijkheid

Systeemeigen gecompileerde opgeslagen procedures moeten schemagebonden zijn, wat betekent dat ze een schemagebonden afhankelijkheid hebben van de door het geheugen geoptimaliseerde tabellen die ze openen en de kolommen waarnaar ze verwijzen. Een schemagebonden afhankelijkheid is een relatie tussen twee entiteiten die verhinderen dat de entiteit waarnaar wordt verwezen, wordt verwijderd of niet compatibel wordt gewijzigd zolang de verwijzende entiteit bestaat.

Als een systeemeigen gecompileerde opgeslagen procedure bijvoorbeeld verwijst naar een kolom c1 uit tabel mytable, kan kolom c1 niet worden verwijderd. Als er een dergelijke procedure is met een INSERT-instructie zonder kolomlijst (bijvoorbeeld INSERT INTO dbo.mytable VALUES (...)), kan er geen kolom in de tabel worden verwijderd.

Logboekregistratie van ALTER TABLE in tabellen die zijn geoptimaliseerd voor geheugen

In een tabel die is geoptimaliseerd voor geheugen, worden de meeste ALTER TABLE-scenario's nu parallel uitgevoerd en resulteert dit in een optimalisatie van schrijfbewerkingen naar het transactielogboek. De optimalisatie wordt bereikt door alleen de metagegevenswijzigingen in het transactielogboek te registreren. De volgende ALTER TABLE-bewerkingen worden echter met één thread uitgevoerd en zijn niet geoptimaliseerd voor logboeken.

Met de bewerking met één thread in dit geval wordt de volledige inhoud van de gewijzigde tabel in het transactielogboek vastgelegd. Een lijst met bewerkingen met één thread volgt:

• Een kolom wijzigen of toevoegen om een groot objecttype (LOB) te gebruiken: nvarchar(max), varchar(max) of varbinary(max).

• Een COLUMNSTORE-index toevoegen of verwijderen.

• Bijna alles wat van invloed is op een afwijkende kolom.

  • Zorg ervoor dat een kolom die op een rij staat, buiten de rij wordt geplaatst.
  • Ervoor zorgen dat een kolom van buiten de rij naar binnen wordt verplaatst.
  • Maak een nieuwe kolom buiten rij.
  • Uitzondering: Het verkorten van een kolom die al buiten de rij staat, wordt op de geoptimaliseerde manier vastgelegd.

Voorbeelden

In het volgende voorbeeld wordt het aantal buckets van een bestaande hash-index gewijzigd. Hiermee wordt de hash-index opnieuw opgebouwd met het aantal nieuwe buckets, terwijl andere eigenschappen van de hash-index hetzelfde blijven.

ALTER TABLE Sales.SalesOrderDetail_inmem
       ALTER INDEX imPK_SalesOrderDetail_SalesOrderID_SalesOrderDetailID  
              REBUILD WITH (BUCKET_COUNT=67108864);  
GO

In het volgende voorbeeld wordt een kolom met een NOT NULL-beperking en een STANDAARDdefinitie toegevoegd en wordt MET WAARDEN gebruikt om waarden op te geven voor elke bestaande rij in de tabel. Als WITH VALUES niet wordt gebruikt, heeft elke rij de waarde NULL in de nieuwe kolom.

ALTER TABLE Sales.SalesOrderDetail_inmem  
       ADD Comment NVARCHAR(100) NOT NULL DEFAULT N'' WITH VALUES;  
GO

In het volgende voorbeeld wordt een primaire-sleutelbeperking toegevoegd aan een bestaande kolom.

CREATE TABLE dbo.UserSession (
   SessionId int not null,
   UserId int not null,
   CreatedDate datetime2 not null,
   ShoppingCartId int,
   index ix_UserId nonclustered hash (UserId) with (bucket_count=400000)
)
WITH (MEMORY_OPTIMIZED=ON, DURABILITY=SCHEMA_ONLY) ;  
GO  
  
ALTER TABLE dbo.UserSession  
       ADD CONSTRAINT PK_UserSession PRIMARY KEY NONCLUSTERED (SessionId);  
GO

In het volgende voorbeeld wordt een index verwijderd.

ALTER TABLE Sales.SalesOrderDetail_inmem  
       DROP INDEX ix_ModifiedDate;  
GO

In het volgende voorbeeld wordt een index toegevoegd.

ALTER TABLE Sales.SalesOrderDetail_inmem  
       ADD INDEX ix_ModifiedDate (ModifiedDate);  
GO  

In het volgende voorbeeld worden meerdere kolommen toegevoegd, met een index en beperkingen.

ALTER TABLE Sales.SalesOrderDetail_inmem  
       ADD    CustomerID int NOT NULL DEFAULT -1 WITH VALUES,  
              ShipMethodID int NOT NULL DEFAULT -1 WITH VALUES,  
              INDEX ix_Customer (CustomerID);  
GO  

Zie ook

Memory-Optimized tabellen