内存优化容器和文件组删除

2025-05-20

适用于： SQL Server 2025 （17.x）预览版和更高版本

在 SQL Server 2022（16.x）和更早版本中，如果为数据库启用了 In-Memory OLTP，即使删除了所有 In-Memory OLTP 对象，最后一个内存优化容器和内存优化文件组也不能删除。因此，In-Memory OLTP 引擎在不使用时继续运行。

从 SQL Server 2025 （17.x）预览版开始，可以通过完全删除数据库中所有内存优化容器和文件组（没有剩余 In-Memory OLTP 对象）来停止 In-Memory OLTP 引擎。

若要删除内存优化容器和文件组并停止 In-Memory OLTP 引擎，

作为验证步骤，连接到数据库并执行以下查询，确认数据库中部署了 In-Memory OLTP （XTP）引擎：
```
SELECT deployment_state,
       deployment_state_desc
FROM sys.dm_db_xtp_undeploy_status;
```
deployment_state列如果为 1 或 2，则部署 In-Memory OLTP 引擎，然后可以执行下面的步骤。 deployment_state如果列为 0，则 In-Memory OLTP 引擎未部署到当前数据库中或已停止，本文的其余部分不适用。

删除数据库中的所有 In-Memory OLTP 对象，包括内存优化表和表类型，以及本机编译的存储过程。

谨慎

此步骤可能会导致当前数据库中内存优化表中永久丢失数据。在继续操作之前，请确保数据不再需要，并备份数据库。

若要在数据库中查找 In-Memory OLTP 对象，请执行以下 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;

有关详细信息，请参阅 DROP TABLE、 DROP PROCEDURE 和 DROP TYPE。

使用 ALTER DATABASE ... REMOVE FILE 语句删除所有内存优化容器。有关详细信息，请参阅 ALTER DATABASE 文件和文件组选项。还可以使用 SQL Server Management Studio（SSMS）中数据库的“数据库属性”对话框中的“文件”页删除内存优化容器。

删除数据库的最后一个内存优化容器将开始删除 In-Memory OLTP 引擎。这是一项长时间运行的作，可能需要执行其他步骤。有关详细信息，请参阅本文后面的步骤以完成最后一个内存优化容器删除。

如果在删除最后一个内存优化容器时取消或中止长时间执行的 ALTER DATABASE ... REMOVE FILE 语句，删除作业可能会部分完成。若要完成删除，可以稍后执行ALTER DATABASE ... REMOVE FILE语句。
使用ALTER DATABASE ... REMOVE FILEGROUP语句或使用 SSMS 的“数据库属性”对话框中的“文件组”页删除内存优化文件组。

内存优化容器和文件组已成功删除，当sys.dm_db_xtp_undeploy_status列的deployment_state值为 0 时，即停止 In-Memory OLTP 引擎。

注释

当数据库具有任何数据库快照时，不支持内存优化容器删除。在删除内存优化容器之前，请先删除所有快照。

完成最后一个内存优化容器删除的步骤

ALTER DATABASE ... REMOVE FILE如果删除最后一个内存优化容器的语句未立即完成，则需要执行其他步骤。

sys.dm_db_xtp_undeploy_status DMV 提供 In-Memory OLTP 引擎删除过程的状态。在以下步骤中，使用此查询来确定当前状态和所需作：

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

deployment_state如果值为 3 且列中的值undeploy_lsn为 0，请执行以下命令：
```
CHECKPOINT;
```
如果deployment_state的值为 3，并且undeploy_lsn列中的值不是 0，则容器删除过程正在等待start_of_log_lsn列中的日志序列号（LSN）超过undeploy_lsn列中的 LSN 值。这需要截断事务日志记录。截断日志：
- 请执行以下命令：
```
CHECKPOINT;
```
  start_of_log_lsn若要超越undeploy_lsn，可能需要多次执行此命令，每次执行命令后等待一分钟。
- 如果数据库使用 “完整 ”或 “大容量日志”恢复模式，则除了执行 CHECKPOINT 命令外，还可能需要确定并解决日志截断延迟的原因，该延迟在 log_reuse_wait_desc 目录视图中的 sys.databases 列中报告。
  
  如果 deployment_state 执行命令后 CHECKPOINT 值仍为 3，请执行以下语句：
```
SELECT name,
       log_reuse_wait_desc
FROM sys.databases
WHERE database_id = DB_ID();
```
  了解日志截断延迟的原因后，请参阅可以延迟日志截断的因素了解详细信息并确定相应的作。
  
  在活动数据库中，事务日志通常在一段时间之后截断，无需任何其他用户操作。例如，如果在 sys.databases 中的 log_reuse_wait_desc 是 LOG_BACKUP，则计划或按需日志备份会截断日志。有关详细信息，请参阅备份事务日志。
  
  如果列中的值 log_reuse_wait_desc 是 NOTHING，但列中的值 deployment_state 仍为 3，请备份事务日志。若要截断事务日志，可能需要进行多个事务日志备份。
deployment_state如果值为 4，则事务日志的活动部分起始点已超出卸载 LSN，容器删除过程正在等待最终的卸载日志记录。在大多数情况下，此步骤在几秒钟内完成，无需执行任何其他作。

如果数据库具有可用性副本，则取消部署记录必须传播并应用于所有副本。如果值 4 长时间保留，请参阅 “确定主要副本的更改为何不会反映在 AlwaysOn 可用性组的次要副本上，以获取详细信息。
如果deployment_state的值为 5，则容器移除过程正在等待最终的 XTP 检查点操作完成。若要立即启动检查点，请执行以下命令：
```
CHECKPOINT;
```
事务日志增长到特定阈值后，会自动执行 XTP 检查点。有关详细信息，请参阅 Memory-Optimized 表的检查点作。
最终的 XTP 检查点作完成后，最后一个内存优化容器的删除将成功完成，列中的值 deployment_state 变为 0。
deployment_state如果值为 6，则表示ALTER DATABASE ... REMOVE FILE最后一个内存优化容器的语句已取消或中止。再次执行该语句以完成容器删除。

通过

内存优化容器和文件组删除

完成最后一个内存优化容器删除的步骤

相关内容

其他资源