메모리 최적화 컨테이너 및 파일 그룹 제거

적용 대상: 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 엔진을 중지하려면 다음을 수행합니다.

1. 유효성 검사 단계로 데이터베이스에 연결하고 다음 쿼리를 실행하여 In-Memory OLTP(OLTP) 엔진이 데이터베이스에 배포되어 있는지 확인합니다.

   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 엔진이 현재 데이터베이스에 배포되지 않았거나 이미 중지되었으며 이 문서의 나머지 부분에서는 적용되지 않습니다.

2. 메모리 최적화 테이블 및 테이블 형식 및 고유하게 컴파일된 저장 프로시저를 포함하여 데이터베이스의 모든 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을 참조하세요.

3. ALTER DATABASE ... REMOVE FILE 구문을 사용하여 메모리 최적화 컨테이너를 모두 제거합니다. 자세한 내용은 ALTER DATABASE 파일 및 파일 그룹 옵션을 참조하세요. SSMS(SQL Server Management Studio)의 데이터베이스에 대한 데이터베이스 속성 대화 상자의 파일 페이지를 사용하여 메모리 최적화 컨테이너를 제거할 수도 있습니다.

   데이터베이스에 대한 마지막 메모리 최적화 컨테이너를 제거하면 In-Memory OLTP 엔진이 제거됩니다. 이는 추가 단계가 필요할 수 있는 장기 실행 작업입니다. 자세한 내용은 이 문서의 뒷부분에 있는 마지막 메모리 최적화 컨테이너 제거를 완료하는 단계를 참조하세요.

   마지막 메모리 최적화 컨테이너를 제거하는 동안 장기 실행 ALTER DATABASE ... REMOVE FILE 문을 취소하거나 중단하면 제거가 부분적으로 완료될 수 있습니다. 제거를 완료하려면 나중에 ALTER DATABASE ... REMOVE FILE 문을 실행하면 됩니다.

4. ALTER DATABASE ... REMOVE FILEGROUP 문을 사용하거나 SSMS의 데이터베이스 속성 대화 상자에서 파일그룹 페이지를 통해 메모리 최적화 파일그룹을 제거합니다.

메모리 최적화 컨테이너 및 파일 그룹의 제거가 성공하고 열의 값 deployment_statesys.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;

1. 값이 deployment_state 3이고 열의 값이 undeploy_lsn 0이면 다음 명령을 실행합니다.

   CHECKPOINT;
   

2. 값이 deployment_state 3이고 열의 undeploy_lsn 값이 0이 아닌 경우 컨테이너 제거 프로세스는 열의 LSN(로그 시퀀스 번호) start_of_log_lsn 이 열의 LSN 값 undeploy_lsn 이상으로 진행되기를 기다리고 있습니다. 이렇게 하려면 트랜잭션 로그를 잘라야 합니다. 로그를 자르려면 다음을 수행합니다.

   • 다음 명령을 실행합니다.

     CHECKPOINT;
     

     start_of_log_lsn를 undeploy_lsn를 넘어서 진행하려면 각 명령 실행 후에 1분을 기다리며 이 명령을 여러 번 실행해야 할 수 있습니다.

   • 데이터베이스에서 전체 또는 대량 로그복구 모델을 사용하는 경우, 명령을 실행하는 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();
     

     로그 잘림이 지연되는 이유를 알고 나면 로그 잘림을 지연할 수 있는 요인 을 참조하여 자세한 내용을 확인하고 적절한 작업을 확인하세요.

     활성 데이터베이스에서 트랜잭션 로그는 일반적으로 추가 사용자 작업 없이 일정 시간 후에 잘립니다. 예를 들어, log_reuse_wait_desc의 sys.databases가 LOG_BACKUP이면, 예약되거나 요청 시 로그 백업이 로그를 절단합니다. 자세한 내용은 트랜잭션 로그 백업을 참조하세요.

     log_reuse_wait_desc 열의 값이 NOTHING이고, deployment_state 열의 값이 3으로 유지되는 경우 트랜잭션 로그를 백업합니다. 트랜잭션 로그를 자르려면 둘 이상의 트랜잭션 로그 백업을 수행해야 할 수 있습니다.

3. 값이 deployment_state 4이면 트랜잭션 로그의 활성 부분 시작이 배포되지 않은 LSN 이상으로 진행되고 컨테이너 제거 프로세스가 최종 배포 취소 로그 레코드를 기다리고 있습니다. 대부분의 경우 이 단계는 추가 작업 없이 몇 초 내에 완료됩니다.

   데이터베이스에 가용성 복제본이 있는 경우 배포 취소 레코드가 전파되어 모든 복제본에 적용되어야 합니다. 값 4가 오랫동안 지속되는 경우 자세한 내용은 Always On 가용성 그룹의 보조 복제본에 주 복제본의 변경 내용이 반영되지 않는 이유를 확인 하세요.

4. 값이 deployment_state 5이면 컨테이너 제거 프로세스가 최종 XTP 검사점 작업이 완료되기를 기다리고 있습니다. 검사점을 즉시 시작하려면 다음 명령을 실행합니다.

   CHECKPOINT;
   

   트랜잭션 로그가 특정 임계값으로 증가하면 XTP 검사점이 자동으로 발생합니다. 자세한 내용은 Memory-Optimized 테이블에 대한 검사점 작업을 참조하세요.

5. 최종 XTP 검사점 작업이 완료되면 마지막 메모리 최적화 컨테이너 제거가 성공적으로 완료되고 열의 deployment_state 값이 0이 됩니다.

6. 값이 deployment_state 6이면 마지막 메모리 최적화 컨테이너에 대한 문이 취소되거나 중단되었음을 의미 ALTER DATABASE ... REMOVE FILE 합니다. 문을 다시 실행하여 컨테이너 제거를 완료합니다.

관련 콘텐츠

• sys.dm_db_xtp_undeploy_status
• 메모리 내 OLTP 개요 및 사용 시나리오
• 메모리 최적화 파일 그룹
• ALTER DATABASE(Transact-SQL) 파일 및 파일 그룹 옵션