Dela via

Minnesoptimerad container och borttagning av filgrupper

Gäller för: Förhandsversion av SQL Server 2025 (17.x) och senare versioner

Om In-Memory OLTP har aktiverats för en databas i SQL Server 2022 (16.x) och äldre versioner kan den senaste minnesoptimerade containern och den minnesoptimerade filgruppen inte tas bort även om alla In-Memory OLTP-objekt tas bort. Därför fortsätter den In-Memory OLTP-motorn att köras när den inte används.

Från och med förhandsversionen av SQL Server 2025 (17.x) kan In-Memory OLTP-motorn stoppas genom att helt ta bort alla minnesoptimerade containrar och filgrupper i databaser utan återstående In-Memory OLTP-objekt.

Ta bort de minnesoptimerade containrarna och filgruppen och stoppa In-Memory OLTP-motorn:

  1. Som ett verifieringssteg ansluter du till databasen och kör följande fråga för att bekräfta att In-Memory OLTP-motorn (XTP) distribueras i databasen:

    SELECT deployment_state,
       deployment_state_desc
FROM sys.dm_db_xtp_undeploy_status;

    Om deployment_state kolumnen är 1 eller 2 distribueras OLTP-motorn In-Memory, och du kan fortsätta med följande steg. deployment_state Om kolumnen är 0 distribueras inte In-Memory OLTP-motorn i den aktuella databasen eller har redan stoppats och resten av den här artikeln gäller inte.

  2. Släpp alla In-Memory OLTP-objekt i databasen, inklusive minnesoptimerade tabeller och tabelltyper, och inbyggda kompilerade lagrade procedurer.

    Försiktighet

    Det här steget kan orsaka permanent dataförlust i de minnesoptimerade tabellerna i den aktuella databasen. Innan du fortsätter kontrollerar du att data inte behövs och gör en säkerhetskopia av databasen.

    Kör följande T-SQL-instruktioner för att hitta In-Memory OLTP-objekt i en databas:

    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;

    Mer information finns i DROP TABLE, DROP PROCEDURE och DROP TYPE.

  3. Ta bort alla minnesoptimerade containrar med hjälp av -instruktionen ALTER DATABASE ... REMOVE FILE . Mer information finns i ALTER DATABASE-fil- och filgruppsalternativ. Du kan också ta bort minnesoptimerade containrar med hjälp av sidan Filer i dialogrutan Databasegenskaper för databasen i SQL Server Management Studio (SSMS).

    Om du tar bort den senaste minnesoptimerade containern för databasen startas borttagningen av In-Memory OLTP-motorn. Det här är en tidskrävande åtgärd som kan kräva ytterligare steg. Mer information finns i Steg för att slutföra den senaste minnesoptimerade containerborttagningen senare i den här artikeln.

    Om du avbryter eller stoppar en tidskrävande ALTER DATABASE ... REMOVE FILE instruktion medan du tar bort den sista minnesoptimerade containern kan borttagningen vara endast delvis genomförd. Om du vill slutföra borttagningen kan du köra -instruktionen ALTER DATABASE ... REMOVE FILE senare.

  4. Ta bort den minnesoptimerade filgruppen med instruktionen ALTER DATABASE ... REMOVE FILEGROUP eller använd sidan Filgrupper i dialogrutan Databasegenskaper i SSMS.

Borttagningen av de minnesoptimerade containrarna och filgruppen lyckas och In-Memory OLTP-motorn stoppas när värdet i deployment_state kolumnen i sys.dm_db_xtp_undeploy_status är 0.

Anmärkning

Minnesoptimerad borttagning av containrar stöds inte när databasen har några ögonblicksbilder av databasen. Ta bort alla ögonblicksbilder innan du tar bort minnesoptimerade containrar.

Steg för att slutföra den sista minnesoptimerade containerborttagningen

Om instruktionen ALTER DATABASE ... REMOVE FILE för att ta bort den senaste minnesoptimerade containern inte slutförs omedelbart krävs ytterligare steg.

Sys.dm_db_xtp_undeploy_status DMV ger status för In-Memory OLTP-motorns borttagningsprocess. I följande steg använder du den här frågan för att fastställa aktuell status och nödvändiga åtgärder:

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

  1. Om värdet deployment_state är 3 och värdet i undeploy_lsn kolumnen är 0 kör du följande kommando:

    CHECKPOINT;

  2. deployment_state Om värdet är 3 och värdet i undeploy_lsn kolumnen är annat än 0 väntar containerborttagningsprocessen på att loggsekvensnumret (LSN) i start_of_log_lsn kolumnen ska gå längre än LSN-värdet i undeploy_lsn kolumnen. Detta kräver att transaktionsloggen avkortas. Så här trunkerar du loggen:

    • Kör följande kommando:

      CHECKPOINT;

      För att gå vidare start_of_log_lsn förbi undeploy_lsn kan du behöva köra det här kommandot flera gånger och vänta en minut efter varje kommandokörning.

    • Om databasen använder Fullständig eller Massloggadåterställningsmodell, kan du, förutom att köra CHECKPOINT-kommandon, behöva fastställa och åtgärda orsaken till fördröjningen i loggtrunkeringen, som rapporteras i log_reuse_wait_desc-kolumnen i sys.databases-katalogvyn.

      Om deployment_state värdet förblir 3 efter att kommandona CHECKPOINT har körts kör du följande instruktion:

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

      När du vet orsaken till fördröjningen av loggtrunkeringen kan du läsa Faktorer som kan fördröja loggtrunkeringen för mer information och för att fastställa lämplig åtgärd.

      I aktiva databaser trunkeras transaktionsloggen vanligtvis efter en tid utan ytterligare användaråtgärder. Om log_reuse_wait_desc i sys.databases till exempel är LOG_BACKUP, trunkerar schemalagda eller på begäran loggsäkerhetskopior loggen. Mer information finns i Säkerhetskopiera en transaktionslogg.

      Om värdet i log_reuse_wait_desc kolumnen är NOTHING, men värdet i deployment_state kolumnen förblir 3, säkerhetskopierar du transaktionsloggen. Om du vill trunkera transaktionsloggen kan du behöva göra mer än en säkerhetskopiering av transaktionsloggen.

  3. deployment_state Om värdet är 4 har starten av den aktiva delen av transaktionsloggen avancerat bortom LSN för odistribution och processen för borttagning av containrar väntar på den sista avdistributionsloggposten. I de flesta fall slutförs det här steget inom några sekunder utan någon ytterligare åtgärd.

    Om databasen har tillgänglighetsrepliker måste avdistributionsposten spridas och tillämpas på alla repliker. Om värdet 4 bevaras under en längre tid kan du läsa Ta reda på varför ändringar från den primära repliken inte återspeglas på den sekundära repliken för en AlwaysOn-tillgänglighetsgrupp för mer information.

  4. Om värdet deployment_state är 5 väntar containerborttagningsprocessen på att den sista XTP-kontrollpunktsåtgärden ska slutföras. Starta en kontrollpunkt omedelbart genom att köra följande kommando:

    CHECKPOINT;

    En XTP-kontrollpunkt inträffar automatiskt när transaktionsloggen har ökat med ett visst tröskelvärde. Mer information finns i Kontrollpunktsåtgärd för Memory-Optimized tabeller.

  5. När den sista XTP-kontrollpunktsåtgärden deployment_state är klar slutförs borttagningen av den senaste minnesoptimerade containern och värdet i kolumnen blir 0.

  6. Om värdet deployment_state är 6 innebär det att instruktionen ALTER DATABASE ... REMOVE FILE för den senaste minnesoptimerade containern avbröts. Utför instruktionen igen för att slutföra borttagningen av containern.

Relaterat innehåll