Delen via

Voor geheugen geoptimaliseerde container- en bestandsgroepverwijdering

Van toepassing op: SQL Server 2025 (17.x) Preview en latere versies

In SQL Server 2022 (16.x) en oudere versies, als In-Memory OLTP is ingeschakeld voor een database, kunnen de laatste voor geheugen geoptimaliseerde container en de door het geheugen geoptimaliseerde bestandsgroep niet worden verwijderd, zelfs niet als alle In-Memory OLTP-objecten worden verwijderd. Als gevolg hiervan blijft de In-Memory OLTP-engine actief wanneer deze niet in gebruik is.

Vanaf SQL Server 2025 (17.x) Preview kan de In-Memory OLTP-engine worden gestopt door alle voor geheugen geoptimaliseerde containers en bestandsgroepen in databases volledig te verwijderen zonder resterende In-Memory OLTP-objecten.

Als u de voor geheugen geoptimaliseerde containers en bestandsgroep wilt verwijderen, stopt u de In-Memory OLTP-engine:

  1. Als validatiestap maakt u verbinding met de database en voert u de volgende query uit om te controleren of de In-Memory OLTP-engine (XTP) is geïmplementeerd in de database:

    SELECT deployment_state,
       deployment_state_desc
FROM sys.dm_db_xtp_undeploy_status;

    Als de deployment_state kolom 1 of 2 is, wordt de In-Memory OLTP-engine geïmplementeerd en kunt u doorgaan met de volgende stappen. Als de deployment_state kolom 0 is, is de In-Memory OLTP-engine niet geïmplementeerd in de huidige database of is deze al gestopt en is de rest van dit artikel niet van toepassing.

  2. Verwijder alle In-Memory OLTP-objecten in de database, inclusief tabellen en tabeltypen die zijn geoptimaliseerd voor geheugen, en systeemeigen opgeslagen procedures.

    Waarschuwing

    Deze stap kan leiden tot permanent verlies van gegevens in de tabellen die zijn geoptimaliseerd voor geheugen in de huidige database. Voordat u doorgaat, moet u ervoor zorgen dat de gegevens niet nodig zijn en een back-up van de database maken.

    Als u In-Memory OLTP-objecten in een database wilt zoeken, voert u de volgende T-SQL-instructies uit:

    USE [<database-name-placeholder>];

/* memory-optimized tables */
SELECT object_id,
       OBJECT_SCHEMA_NAME(object_id) AS schema_name,
       name AS table_name
FROM sys.tables
WHERE is_memory_optimized = 1;

/* natively compiled modules */
SELECT object_id,
       OBJECT_SCHEMA_NAME(object_id) AS schema_name,
       OBJECT_NAME(object_id) AS module_name
FROM sys.all_sql_modules
WHERE uses_native_compilation = 1;

/* memory-optimized table types */
SELECT SCHEMA_NAME(schema_id) AS type_schema_name,
       name AS type_name,
       OBJECT_NAME(type_table_object_id) AS type_table_name
FROM sys.table_types
WHERE is_memory_optimized = 1;

    Zie DROP TABLE, DROP PROCEDURE en DROP TYPE voor meer informatie.

  3. Verwijder alle containers die zijn geoptimaliseerd voor geheugen met behulp van de ALTER DATABASE ... REMOVE FILE instructie. Zie ALTER DATABASE File and Filegroup Optionsvoor meer informatie. U kunt ook containers die zijn geoptimaliseerd voor geheugen verwijderen met behulp van de pagina Bestanden in het dialoogvenster Database-eigenschappen voor uw database in SQL Server Management Studio (SSMS).

    Als u de laatste voor het geheugen geoptimaliseerde container voor de database verwijdert, start de verwijdering van de In-Memory OLTP-engine. Dit is een langdurige bewerking waarvoor mogelijk extra stappen nodig zijn. Zie Stappen voor het voltooien van het laatst voor geheugen geoptimaliseerde containerverwijdering verderop in dit artikel voor meer informatie.

    Als u een langlopende ALTER DATABASE ... REMOVE FILE instructie annuleert of afbreekt tijdens het verwijderen van de laatst geoptimaliseerde container voor geheugen, is het verwijderen mogelijk gedeeltelijk voltooid. Als u de verwijdering wilt voltooien, kunt u de ALTER DATABASE ... REMOVE FILE instructie later uitvoeren.

  4. Verwijder de voor geheugen geoptimaliseerde bestandsgroep met behulp van de ALTER DATABASE ... REMOVE FILEGROUP instructie of gebruik de pagina Bestandsgroepen in het dialoogvenster Database-eigenschappen in SSMS.

Het verwijderen van de voor geheugen geoptimaliseerde containers en bestandsgroep is geslaagd en de In-Memory OLTP-engine wordt gestopt wanneer de waarde in de deployment_state kolom in sys.dm_db_xtp_undeploy_status 0 is.

Opmerking

Het verwijderen van containers die zijn geoptimaliseerd voor geheugen wordt niet ondersteund wanneer de database momentopnamen van de database bevat. Verwijder alle momentopnamen voordat u containers verwijdert die zijn geoptimaliseerd voor geheugen.

Stappen voor het verwijderen van de laatst overgebleven geheugen-geoptimaliseerde container

Als de instructie voor het verwijderen van de ALTER DATABASE ... REMOVE FILE laatste voor geheugen geoptimaliseerde container niet onmiddellijk wordt voltooid, zijn er aanvullende stappen vereist.

De DMV sys.dm_db_xtp_undeploy_status biedt de status van het verwijderingsproces van de In-Memory OLTP-engine. Gebruik in de volgende stappen deze query om de huidige status en de vereiste acties te bepalen:

SELECT deployment_state,
       deployment_state_desc,
       undeploy_lsn,
       start_of_log_lsn
FROM sys.dm_db_xtp_undeploy_status;

  1. Als de deployment_state waarde 3 is en de waarde in de undeploy_lsn kolom 0 is, voert u de volgende opdracht uit:

    CHECKPOINT;

  2. Als de deployment_state waarde 3 is en de waarde in de undeploy_lsn kolom anders is dan 0, wacht het verwijderingsproces van de container op het logboekreeksnummer (LSN) in de start_of_log_lsn kolom om verder te gaan dan de LSN-waarde in de undeploy_lsn kolom. Hiervoor moet het transactielogboek worden ingekort. Het logbestand verkorten:

    • Voer de volgende opdracht uit:

      CHECKPOINT;

      Als u verder wilt gaan start_of_log_lsnundeploy_lsn, moet u deze opdracht mogelijk meerdere keren uitvoeren en een minuut wachten na elke uitvoering van de opdracht.

    • Als de database gebruikmaakt van het volledig of bulk-gelogdeherstelmodel, moet u, naast het uitvoeren van de CHECKPOINT opdrachten, mogelijk de reden voor de vertraging in de logboektruncatie bepalen en aanpakken. Deze wordt gerapporteerd in de log_reuse_wait_desc kolom in de sys.databases catalogusweergave.

      Indien de deployment_state waarde 3 blijft na het uitvoeren van de CHECKPOINT opdrachten, voert u de volgende instructie uit:

      SELECT name,
       log_reuse_wait_desc
FROM sys.databases
WHERE database_id = DB_ID();

      Zodra u de reden voor de vertraging in afkapping van logboeken weet, raadpleegt u Factoren die de afkapping van logboeken kunnen vertragen voor meer informatie en om de juiste actie te bepalen.

      In actieve databases wordt transactielogboek meestal na enige tijd afgekapt zonder extra gebruikersactie. Als log_reuse_wait_desc in sys.databasesLOG_BACKUP is, worden logboekback-ups gepland of op aanvraag uitgevoerd om het logboek te verkorten. Zie Een back-up maken van een transactielogboek voor meer informatie.

      Als de waarde in de log_reuse_wait_desc kolom is NOTHING, maar de waarde in deployment_state kolom 3 blijft, maakt u een back-up van het transactielogboek. Als u het transactielogboek wilt afkappen, moet u mogelijk meer dan één back-up van het transactielogboek maken.

  3. Als de deployment_state waarde 4 is, is het begin van het actieve gedeelte van het transactielogboek verder gevorderd dan de LSN-ontimplementatie en wacht het containerverwijderingsproces op de laatste logboekrecord voor de ontimplementatie. In de meeste gevallen wordt deze stap binnen een paar seconden voltooid zonder extra actie.

    Als de database beschikbaarheidsreplica's heeft, moet de ongedaanmakingsrecord zich verspreiden en worden toegepast op alle replica's. Als waarde 4 lange tijd blijft bestaan, raadpleegt u Bepalen waarom wijzigingen van primaire replica niet worden doorgevoerd op secundaire replica voor een AlwaysOn-beschikbaarheidsgroep voor meer informatie.

  4. Als de deployment_state waarde 5 is, wacht het containerverwijderingsproces tot de laatste XTP-controlepuntbewerking is voltooid. Voer de volgende opdracht uit om onmiddellijk een controlepunt te starten:

    CHECKPOINT;

    Een XTP-controlepunt vindt automatisch plaats zodra het transactielogboek is gegroeid door een bepaalde drempelwaarde. Zie Controlepuntbewerking voor Memory-Optimized tabellen voor meer informatie.

  5. Zodra de laatste XTP-controlepuntbewerking is voltooid, wordt het verwijderen van de laatst geoptimaliseerde container voor geheugen voltooid en wordt de waarde in de deployment_state kolom 0.

  6. Als de deployment_state waarde 6 is, betekent dit dat de ALTER DATABASE ... REMOVE FILE instructie voor de laatst geoptimaliseerde container voor geheugen is geannuleerd of afgebroken. Voer de instructie opnieuw uit om het verwijderen van containers te voltooien.

Verwante inhoud