Condividi tramite

Rimozione di contenitori e filegroup ottimizzati per la memoria

Si applica a: SQL Server 2025 (17.x) e versioni successive

In SQL Server 2022 (16.x) e versioni precedenti, se In-Memory OLTP è abilitato per un database, l'ultimo contenitore ottimizzato per la memoria e il filegroup ottimizzato per la memoria non possono essere rimossi anche se tutti gli oggetti OLTP In-Memory vengono eliminati. Di conseguenza, il motore OLTP In-Memory rimane attivo quando non viene utilizzato.

A partire da SQL Server 2025 (17.x), il motore OLTP In-Memory può essere arrestato rimuovendo completamente tutti i contenitori e i filegroup ottimizzati per la memoria nei database senza oggetti OLTP In-Memory rimanenti.

Per rimuovere i contenitori ottimizzati per la memoria e il filegroup e arrestare il motore OLTP In-Memory:

  1. Come passaggio di convalida, connettersi al database ed eseguire la query seguente per verificare che il motore OLTP (XTP) In-Memory sia distribuito nel database:

    SELECT deployment_state,
       deployment_state_desc
FROM sys.dm_db_xtp_undeploy_status;

    Se la deployment_state colonna è 1 o 2, viene distribuito il motore OLTP In-Memory ed è possibile procedere con i passaggi seguenti. Se la deployment_state colonna è 0, il motore OLTP In-Memory non viene distribuito nel database corrente o è già stato arrestato e il resto di questo articolo non si applica.

  2. Rimuovere tutti gli oggetti OLTP In-Memory nel database, inclusi le tabelle e i tipi di tabella ottimizzati per la memoria e le stored procedure compilate in modo nativo.

    Attenzione

    Questo passaggio potrebbe causare una perdita permanente di dati nelle tabelle ottimizzate per la memoria nel database corrente. Prima di procedere, assicurarsi che i dati non siano necessari ed eseguire un backup del database.

    Per trovare In-Memory oggetti OLTP in un database, eseguire le istruzioni T-SQL seguenti:

    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;

    Per altre informazioni, vedere DROP TABLE, DROP PROCEDURE e DROP TYPE.

  3. Rimuovere tutti i contenitori ottimizzati per la memoria usando l'istruzione ALTER DATABASE ... REMOVE FILE . Per altre informazioni, vedere Opzioni per file e filegroup ALTER DATABASE. È anche possibile rimuovere i contenitori ottimizzati per la memoria usando la pagina File nella finestra di dialogo Proprietà database per il database in SQL Server Management Studio (SSMS).

    La rimozione dell'ultimo contenitore ottimizzato per la memoria per il database avvia la rimozione del motore OLTP In-Memory. Si tratta di un'operazione a esecuzione prolungata che potrebbe richiedere passaggi aggiuntivi. Per ulteriori informazioni, vedere Passaggi per completare la rimozione finale dei contenitori ottimizzati per la memoria più avanti in questo articolo.

    Se si annulla o si interrompe un'istruzione a esecuzione ALTER DATABASE ... REMOVE FILE prolungata durante la rimozione dell'ultimo contenitore ottimizzato per la memoria, la rimozione potrebbe essere parzialmente completata. Per completare la rimozione, è possibile eseguire l'istruzione ALTER DATABASE ... REMOVE FILE in un secondo momento.

  4. Rimuovere il gruppo di file ottimizzato per la memoria usando l'istruzione ALTER DATABASE ... REMOVE FILEGROUP o la pagina Gruppi di file nella finestra di dialogo Proprietà Database in SSMS.

La rimozione dei contenitori e del filegroup ottimizzati per la memoria ha esito positivo, e il motore OLTP In-Memory viene arrestato quando il valore nella colonna deployment_state in sys.dm_db_xtp_undeploy_status è 0.

Annotazioni

La rimozione di contenitori ottimizzati per la memoria non è supportata quando il database include snapshot del database. Eliminare tutti gli snapshot prima di rimuovere i contenitori ottimizzati per la memoria.

Passaggi per completare la rimozione dell'ultimo contenitore ottimizzato per la memoria

Se l'istruzione ALTER DATABASE ... REMOVE FILE per rimuovere l'ultimo contenitore ottimizzato per la memoria non viene completata immediatamente, sono necessari passaggi aggiuntivi.

Il DMV sys.dm_db_xtp_undeploy_status fornisce lo stato del processo di rimozione del motore OLTP In-Memory. Nei passaggi seguenti usare questa query per determinare lo stato corrente e le azioni necessarie:

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

  1. Se il deployment_state valore è 3 e il valore nella undeploy_lsn colonna è 0, eseguire il comando seguente:

    CHECKPOINT;

  2. Se il deployment_state valore è 3 e il valore nella undeploy_lsn colonna è diverso da 0, il processo di rimozione del contenitore è in attesa del numero di sequenza del log (LSN) nella start_of_log_lsn colonna per andare oltre il valore LSN nella undeploy_lsn colonna. È quindi necessario che il log delle transazioni venga troncato. Per truncare il log:

    • Eseguire il comando seguente:

      CHECKPOINT;

      Per andare start_of_log_lsn oltre undeploy_lsn, potrebbe essere necessario eseguire questo comando più volte, in attesa di un minuto dopo ogni esecuzione del comando.

    • Se il database usa il modello di recuperocon registrazione completao con registrazione minima delle operazioni bulk, oltre a eseguire i CHECKPOINT comandi, potrebbe essere necessario determinare e risolvere il motivo del ritardo nel troncamento del log, che viene segnalato nella log_reuse_wait_desc colonna nella sys.databases vista del catalogo.

      Se deployment_state il valore rimane 3 dopo l'esecuzione dei CHECKPOINT comandi, eseguire l'istruzione seguente:

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

      Dopo aver appreso il motivo del ritardo nel troncamento del log, vedere Fattori che possono ritardare il troncamento del log per altre informazioni e determinare l'azione appropriata.

      Nei database attivi, il log delle transazioni viene in genere troncato dopo qualche tempo senza alcuna azione aggiuntiva dell'utente. Ad esempio, se log_reuse_wait_desc in sys.databases è LOG_BACKUP, i backup del log pianificati o su richiesta troncano il log. Per altre informazioni, vedere Eseguire il backup di un log delle transazioni.

      Se il valore nella log_reuse_wait_desc colonna è NOTHING, ma il valore nella deployment_state colonna rimane 3, eseguire il backup del log delle transazioni. Per troncare il log delle transazioni, potrebbe essere necessario eseguire più di un backup del log delle transazioni.

  3. Se il valore deployment_state è 4, l'inizio della parte attiva del log delle transazioni è avanzato oltre l'LSN dell'annullamento della distribuzione e il processo di rimozione del contenitore è in attesa del record finale del log di annullamento della distribuzione. Nella maggior parte dei casi, questo passaggio viene completato entro pochi secondi senza alcuna azione aggiuntiva.

    Se il database dispone di repliche di disponibilità, il record di annullamento della distribuzione deve propagarsi e applicarlo a tutte le repliche. Se il valore 4 persiste per molto tempo, vedere Determinare il motivo per cui le modifiche dalla replica primaria non vengono riflesse nella replica secondaria per un gruppo di disponibilità AlwaysOn per altre informazioni.

  4. Se il deployment_state valore è 5, il processo di rimozione del contenitore è in attesa del completamento dell'operazione di checkpoint XTP finale. Per avviare immediatamente un checkpoint, eseguire il comando seguente:

    CHECKPOINT;

    Un checkpoint XTP viene generato automaticamente dopo che il log delle transazioni è cresciuto di una determinata soglia. Per ulteriori informazioni, vedere Operazione di checkpoint per le tabelle Memory-Optimized.

  5. Al termine dell'operazione finale del checkpoint XTP, la rimozione dell'ultimo contenitore ottimizzato per la memoria viene completata correttamente e il valore nella deployment_state colonna diventa 0.

  6. Se il deployment_state valore è 6, significa che l'istruzione ALTER DATABASE ... REMOVE FILE per l'ultimo contenitore ottimizzato per la memoria è stata annullata o interrotta. Eseguire di nuovo l'istruzione per completare la rimozione del contenitore.

Contenuti correlati

  • Last updated on