記憶體優化容器和檔案群組移除

2025-05-19

適用於： 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 中 [資料庫屬性] 對話方塊中的 [檔案群組] 頁面。

記憶體優化容器和檔案群組已成功移除，當deployment_state中的sys.dm_db_xtp_undeploy_status欄位值為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，且資料行中的值不是 0，則容器移除程式會等候數據行中的undeploy_lsnstart_of_log_lsn記錄序號（LSN）前進超過資料行中的 undeploy_lsn LSN 值。這需要截斷交易日志。若要截斷記錄檔：
- 執行以下命令：
```
CHECKPOINT;
```
  若要超越 start_of_log_lsnundeploy_lsn，您可能需要執行此命令數次，在每個命令執行后等候一分鐘。
- 如果資料庫使用完整或大容量記錄恢復模式，則除了執行CHECKPOINT命令之外，您可能需要判斷並解決記錄截斷延遲的原因，這會在目錄檢視的log_reuse_wait_descsys.databases欄中報告。
  
  如果在執行 deployment_state 命令之後，CHECKPOINT 值仍為 3，請執行下列語句：
```
SELECT name,
       log_reuse_wait_desc
FROM sys.databases
WHERE database_id = DB_ID();
```
  一旦您知道記錄截斷延遲的原因，請參閱可能會延遲記錄截斷的因素，以取得詳細資訊並判斷適當的動作。
  
  在主動式資料庫中，交易日誌通常會在一段時間後截斷，不需要任何額外的使用者動作。例如，如果 log_reuse_wait_desc in sys.databases 是 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最後一個記憶體優化容器的語句已取消或中止。再次執行語句以完成容器移除。

共用方式為

記憶體優化容器和檔案群組移除

完成最後一個記憶體優化容器移除的步驟

相關內容

意見反應

其他資源