Compartir por

Eliminación de contenedores y grupos de archivos optimizados para memoria

Se aplica a: SQL Server 2025 (17.x) y versiones posteriores

En SQL Server 2022 (16.x) y versiones anteriores, si In-Memory OLTP está habilitado para una base de datos, el último contenedor optimizado para memoria y el grupo de archivos optimizados para memoria no se pueden quitar incluso si se quitan todos los objetos OLTP de In-Memory. Como resultado, el motor de In-Memory OLTP continúa ejecutándose cuando no está en uso.

A partir de SQL Server 2025 (17.x), el motor In-Memory OLTP se puede detener quitando completamente todos los contenedores y grupos de archivos optimizados para memoria en bases de datos sin objetos In-Memory OLTP restantes.

Para quitar los contenedores y grupos de archivos optimizados para memoria y detener el motor OLTP de In-Memory:

  1. Como paso de validación, conéctese a la base de datos y ejecute la siguiente consulta para confirmar que el motor olTP (XTP) de In-Memory está implementado en la base de datos:

    SELECT deployment_state,
       deployment_state_desc
FROM sys.dm_db_xtp_undeploy_status;

    Si la deployment_state columna es 1 o 2, se implementa el In-Memory motor OLTP y puede continuar con los pasos siguientes. Si la deployment_state columna es 0, el motor de In-Memory OLTP no se implementa en la base de datos actual o ya se ha detenido y el resto de este artículo no se aplica.

  2. Quite todos los objetos OLTP In-Memory de la base de datos, incluidas las tablas y tipos de tabla optimizadas para memoria, y los procedimientos almacenados compilados de forma nativa.

    Precaución

    Este paso puede provocar una pérdida permanente de datos en las tablas optimizadas para memoria de la base de datos actual. Antes de continuar, asegúrese de que los datos no son necesarios y realice una copia de seguridad de la base de datos.

    Para buscar In-Memory objetos OLTP en una base de datos, ejecute las siguientes instrucciones T-SQL:

    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;

    Para obtener más información, vea DROP TABLE, DROP PROCEDURE y DROP TYPE.

  3. Quite todos los contenedores optimizados para memoria mediante la ALTER DATABASE ... REMOVE FILE instrucción . Para más información, consulte Opciones File y Filegroup de ALTER DATABASE. También puede quitar contenedores optimizados para memoria mediante la página Archivos del cuadro de diálogo Propiedades de la base de datos de la base de datos en SQL Server Management Studio (SSMS).

    Al quitar el último contenedor optimizado para memoria de la base de datos, se inicia la eliminación del motor OLTP de In-Memory. Se trata de una operación de larga duración que puede requerir pasos adicionales. Para obtener más información, consulte Pasos para completar la última eliminación del contenedor optimizado para memoria más adelante en este artículo.

    Si cancela o anula una instrucción de ejecución ALTER DATABASE ... REMOVE FILE prolongada al quitar el último contenedor optimizado para memoria, es posible que la eliminación se complete parcialmente. Para completar la eliminación, puede ejecutar la ALTER DATABASE ... REMOVE FILE instrucción más adelante.

  4. Quite el grupo de archivos optimizados para memoria mediante la ALTER DATABASE ... REMOVE FILEGROUP instrucción o use la página Grupos de archivos del cuadro de diálogo Propiedades de la base de datos en SSMS.

La eliminación de los contenedores y grupos de archivos optimizados para memoria se realiza correctamente y el motor OLTP de In-Memory se detiene cuando el valor de la deployment_state columna de sys.dm_db_xtp_undeploy_status es 0.

Nota:

No se admite la eliminación de contenedores optimizados para memoria cuando la base de datos tiene instantáneas de base de datos. Elimine todas las instantáneas antes de quitar los contenedores optimizados para la memoria.

Pasos para completar la eliminación del último contenedor optimizado para memoria

Si la ALTER DATABASE ... REMOVE FILE instrucción para quitar el último contenedor optimizado para memoria no se completa inmediatamente, se requieren pasos adicionales.

El sys.dm_db_xtp_undeploy_status DMV ofrece el estado del proceso de eliminación del motor OLTP de In-Memory. En los pasos siguientes, use esta consulta para determinar el estado actual y las acciones necesarias:

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

  1. Si el deployment_state valor es 3 y el valor de la undeploy_lsn columna es 0, ejecute el siguiente comando:

    CHECKPOINT;

  2. Si el deployment_state valor es 3 y el valor de la undeploy_lsn columna es distinto de 0, el proceso de eliminación del contenedor espera a que el número de secuencia de registro (LSN) de la start_of_log_lsn columna avance más allá del valor LSN de la undeploy_lsn columna. Esto requiere que se trunquen los registros de transacciones. Para truncar el registro:

    • Ejecute el siguiente comando:

      CHECKPOINT;

      Para avanzar start_of_log_lsn más allá undeploy_lsn, es posible que tenga que ejecutar este comando varias veces, esperando un minuto después de cada ejecución del comando.

    • Si la base de datos usa el modelo de recuperacióncompleto o optimizado para cargas masivas de registros, además de ejecutar los CHECKPOINT comandos, es posible que tenga que determinar y solucionar el motivo del retraso en el truncamiento del registro, que se notifica en la columna de la log_reuse_wait_desc vista de sys.databases catálogo.

      Si deployment_state el valor sigue siendo 3 después de ejecutar los CHECKPOINT comandos, ejecute la instrucción siguiente:

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

      Una vez que sepa el motivo del retraso en el truncamiento del registro, consulte Factores que pueden retrasar el truncamiento del registro para obtener más información y determinar la acción adecuada.

      En las bases de datos activas, el registro de transacciones normalmente se trunca después de algún tiempo sin ninguna acción de usuario adicional. Por ejemplo, si log_reuse_wait_desc en sys.databases es LOG_BACKUP, las copias de seguridad de registros programadas o a petición truncan el registro. Para obtener más información, consulte Copia de seguridad de un registro de transacciones.

      Si el valor de la log_reuse_wait_desc columna es NOTHING, pero el valor de la deployment_state columna sigue siendo 3, realice una copia de seguridad del registro de transacciones. Para truncar el registro de transacciones, es posible que tenga que realizar más de una copia de seguridad del registro de transacciones.

  3. Si el valor deployment_state es 4, entonces el inicio de la parte activa del registro de transacciones ha superado el LSN de desimplementación y el proceso de eliminación del contenedor está esperando el registro de desimplementación final. En la mayoría de los casos, este paso se completa en unos segundos sin ninguna acción adicional.

    Si la base de datos tiene réplicas de disponibilidad, el registro de no implementación debe propagarse y aplicarse a todas las réplicas. Si el valor 4 persiste durante mucho tiempo, consulte Determinar por qué los cambios de la réplica principal no se reflejan en la réplica secundaria en un grupo de disponibilidad Always On para obtener más información.

  4. Si el deployment_state valor es 5, el proceso de eliminación del contenedor espera a que se complete la operación de punto de comprobación XTP final. Para iniciar un punto de control inmediatamente, ejecute el siguiente comando:

    CHECKPOINT;

    Un punto de control XTP se produce automáticamente una vez que el registro de transacciones ha crecido por un umbral determinado. Para obtener más información, consulte Operación de punto de control para tablas Memory-Optimized.

  5. Una vez completada la última operación de punto de comprobación de XTP, la eliminación del último contenedor optimizado para memoria se completa correctamente y el valor de la deployment_state columna se convierte en 0.

  6. Si el deployment_state valor es 6, significa que la ALTER DATABASE ... REMOVE FILE instrucción del último contenedor optimizado para memoria se canceló o anuló. Vuelva a ejecutar la instrucción para completar la eliminación del contenedor.

Contenido relacionado

  • Last updated on