Удаление оптимизированных для памяти контейнеров и файловой группы

Применимо к: SQL Server 2025 (17.x) и более поздних версий

В SQL Server 2022 (16.x) и более старых версиях, если для базы данных включена In-Memory OLTP, последний контейнер, оптимизированный для памяти, и оптимизированную для памяти файловую группу нельзя удалить, даже если все In-Memory объекты OLTP удаляются. В результате модуль OLTP In-Memory продолжает работать, если он не используется.

Начиная с SQL Server 2025 (17.x), модуль OLTP In-Memory можно остановить, полностью удалив все оптимизированные для памяти контейнеры и файловые группы в базах данных без оставшихся In-Memory объектов OLTP.

Чтобы удалить оптимизированные для памяти контейнеры и файловую группу и остановить подсистему OLTP In-Memory:

В качестве шага проверки подключитесь к базе данных и выполните следующий запрос, чтобы убедиться, что ядро OLTP (XTP) In-Memory развертывается в базе данных:
```
SELECT deployment_state,
       deployment_state_desc
FROM sys.dm_db_xtp_undeploy_status;
```
deployment_state Если столбец равен 1 или 2, развертывается модуль OLTP In-Memory, и вы можете выполнить следующие действия. deployment_state Если столбец равен 0, подсистема OLTP In-Memory не развертывается в текущей базе данных или уже остановлена, а оставшаяся часть этой статьи не применяется.
Удалите все 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 для файлов и файловых групп (Transact-SQL). Вы также можете удалить контейнеры, оптимизированные для памяти, используя страницу Files в диалоговом окне Свойства базы данных для вашей базы данных в Microsoft SQL Server Management Studio (SSMS).

Удаление последнего оптимизированного для памяти контейнера для базы данных запускает удаление ядра OLTP In-Memory. Это длительная операция, которая может потребовать дополнительных действий. Дополнительные сведения см. в разделе "Действия по выполнению последнего удаления оптимизированных для памяти контейнеров " далее в этой статье.

При отмене или прерывании длительной ALTER DATABASE ... REMOVE FILE инструкции при удалении последнего оптимизированного для памяти контейнера удаление может быть частично завершено. Чтобы завершить удаление, можно выполнить инструкцию ALTER DATABASE ... REMOVE FILE позже.
Удалите файловую группу, оптимизированную для памяти, с помощью инструкции ALTER DATABASE ... REMOVE FILEGROUP или через страницу «Файловые группы» в диалоговом окне «Свойства базы данных» в SSMS.

Удаление оптимизированных для памяти контейнеров и файловой группы успешно завершено, а модуль OLTP In-Memory останавливается, когда значение в deployment_state столбце sys.dm_db_xtp_undeploy_status равно 0.

Замечание

Удаление контейнеров, оптимизированных для памяти, не поддерживается, если в базе данных имеются моментальные снимки базы данных. Удалите все снимки перед удалением оптимизированных для памяти контейнеров.

Шаги по выполнению удаления последнего контейнера, оптимизированного для памяти

ALTER DATABASE ... REMOVE FILE Если инструкция для удаления последнего контейнера, оптимизированного для памяти, не выполняется немедленно, требуются дополнительные действия.

DMV sys.dm_db_xtp_undeploy_status предоставляет информацию о состоянии процесса удаления подсистемы OLTP In-Memory. В следующих шагах используйте этот запрос, чтобы определить текущее состояние и необходимые действия:

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, процесс удаления контейнера ожидает, чтобы номер последовательности журнала (LSN) в столбце start_of_log_lsn продвинулся вперед, превысив значение LSN в столбце undeploy_lsn. Для этого требуется усечение журнала транзакций. Чтобы усечь журнал, выполните следующие действия.
- Выполните следующую команду:
```
CHECKPOINT;
```
  Чтобы перейти start_of_log_lsn за рамки undeploy_lsn, может потребоваться выполнить эту команду несколько раз, ожидая минуту после выполнения каждой команды.
- Если база данных использует модель полного или массового восстановления, то в дополнение к выполнению CHECKPOINT команд может потребоваться определить и устранить причину задержки усечения журнала, которая сообщается в log_reuse_wait_desc столбце в представлении каталога sys.databases.
  
  Если deployment_state значение остается 3 после выполнения CHECKPOINT команд, выполните следующую инструкцию:
```
SELECT name,
       log_reuse_wait_desc
FROM sys.databases
WHERE database_id = DB_ID();
```
  После того как вы узнаете причину задержки усечения журнала, ознакомьтесь с факторами, которые могут отложить усечение журнала для получения дополнительных сведений и чтобы определить соответствующее действие.
  
  В активных базах данных журнал транзакций обычно усечен через некоторое время без каких-либо дополнительных действий пользователя. Например, если log_reuse_wait_desc в 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 инструкция для последнего оптимизированного для памяти контейнера была отменена или прервана. Выполните инструкцию еще раз, чтобы завершить удаление контейнера.

Обратная связь

Была ли эта страница полезна?

Last updated on 2025-05-19

Поделиться через

Удаление оптимизированных для памяти контейнеров и файловой группы

Шаги по выполнению удаления последнего контейнера, оптимизированного для памяти

Связанный контент

Обратная связь

Дополнительные ресурсы