다음을 통해 공유


메모리 최적화 테이블이 포함된 시스템 버전 관리 temporal 테이블

적용 대상: SQL Server 2016(13.x) 이상 Azure SQL 데이터베이스 Azure SQL Managed Instance

메모리 최적화 테이블 에 대한 시스템 버전 관리 temporal 테이블은 메모리 내 OLTP 작업으로 수집한 데이터 위에 데이터 감사 및 특정 시간 분석 이 필요한 시나리오에 대해 비용 효율적인 솔루션을 제공하기 위한 것입니다.

개요

시스템 버전 관리 temporal 테이블은 자동으로 데이터 변경 내용에 대한 전체 기록을 유지하며 특정 시간 분석에 대해 편리한 TRANSACT-SQL 확장을 적용합니다. 일반적인 시나리오에서는 데이터 기록이 정기적으로 쿼리되지 않더라도 긴 시간(여러 달, 심지어 수 년) 동안 보존됩니다.

데이터 감사 및 시간 기반 분석은 서로 다른 환경, 특히 매우 많은 수의 요청을 처리하는 OLTP 시스템에서, 그리고 메모리 내 OLTP 기술을 사용하는 경우에 필요할 수 있습니다. 그러나 메모리 최적화 테이블을 temporal 시나리오에 사용하는 것은 일반적으로 막대한 양의 기록 데이터가 생성되어 사용 가능 RAM의 한계를 초과하기 때문에 어려울 수 있습니다. 동시에 자주 액세스하지 않아서 오래된 읽기 전용 기록 데이터를 RAM에 저장하는 것은 최적의 솔루션이 아닙니다.

메모리 최적화 테이블에 대한 시스템 버전 관리 temporal 테이블은 높은 트랜잭션 처리량 그리고 잠금 없는 동시 실행을 제공하도록 설계되었습니다. 메모리 내 테이블을 사용하여 현재 데이터(temporal 테이블) 및 기록 데이터에 대한 디스크 기반 테이블을 저장하여 많은 양의 기록 데이터를 저장할 수 있습니다. 최근 기록을 저장하고 네이티브 컴파일 코드에서 DML을 실행할 수 있게 하는 내부적으로 자동 생성된 메모리 최적화 준비 테이블을 사용하면 DML 작업에 미치는 영향을 줄일 수 있습니다.

다음 다이어그램은 이 아키텍처를 보여 줍니다.

temporal 메모리 내 아키텍처

구현 세부 정보

시스템 버전 관리 메모리 최적화 테이블을 만들 때는 다음 사항을 고려해야 합니다. 구문 옵션 및 예제는 CREATE TABLE을 참조하세요.

  • 내구성 있는 메모리 최적화 테이블만이 시스템 버전 관리가 가능합니다(DURABILITY = SCHEMA_AND_DATA).

  • 메모리 최적화 시스템 버전 관리 테이블에 대한 기록 테이블은 만든 주체가 최종 사용자이든 또는 시스템이든 상관없이 디스크 기반이어야 합니다.

  • 현재 메모리 내 테이블에만 영향을 주는 쿼리를 고유하게 컴파일된 T-SQL 모듈에서 사용할 수 있습니다. FOR SYSTEM TIME 절을 사용하는 temporal 쿼리는 고유하게 컴파일된 모듈에서 지원되지 않습니다. FOR SYSTEM TIME 절은 temporal 쿼리와 비 네이티브 모듈에서 메모리 최적화된 테이블을 통해 지원됩니다.

  • SYSTEM_VERSIONING = ON을 사용하면 최신 시스템 버전 변경 내용을 수용하기 위해 내부 메모리 최적화 준비 테이블이 자동으로 생성됩니다. 이러한 변경 내용은 현재 메모리 최적화 테이블에서 수행된 업데이트 및 삭제 작업의 결과입니다.

  • 내부 메모리 최적화 준비 테이블의 데이터는 비동기 데이터 플러시 태스크에 의해 정기적으로 디스크 기반 기록 테이블로 이동됩니다. 이 데이터 플러시 메커니즘의 목표는 내부 메모리 버퍼를 상위 개체의 메모리 소비량의 10% 미만으로 유지하는 것입니다. sys.dm_db_xtp_memory_consumers를 쿼리하고 메모리 최적화 준비 테이블 및 현재 temporal 테이블에 대한 데이터를 요약하면 메모리 최적화 시스템 버전 관리 temporal 테이블의 총 메모리 소비량을 추적할 수 있습니다.

  • sp_xtp_flush_temporal_history를 실행하여 데이터 플러시를 수동으로 실행할 수 있습니다.

  • SYSTEM_VERSIONING = OFF를 사용하거나 시스템 버전 관리 테이블의 스키마가 열 추가, 삭제 또는 변경으로 수정되면 내부 스테이징 버퍼의 전체 내용이 디스크 기반 기록 테이블로 이동됩니다.

  • 기록 데이터 쿼리는 결과적으로 스냅샷 격리 수준 아래에 있으며 언제나 메모리 내 준비 버퍼와 디스크 기반 테이블 사이의 합집합을 중복 없이 반환합니다.

  • 내부적으로 테이블 스키마를 변경하는ALTER TABLE 작업은 작업 기간이 오래 걸릴 수 있는 데이터 플래시를 수행해야 합니다.

내부 메모리 액세스에 최적화된 준비 테이블

시스템은 내부 메모리 최적화 준비 테이블을 만들어 DML 작업을 최적화합니다.

  • 테이블 이름은 Memory_Optimized_History_Table_<object_id> 형식으로 생성됩니다. 여기서 <object_id>는 현재 시간 테이블의 식별자입니다.

  • 테이블은 현재 temporal 테이블에 bigint 열 한 개를 더한 스키마를 복제합니다. 이 추가 열은 내부 기록 버퍼로 이동되는 행의 고유성을 보장합니다.

  • 추가 열 이름의 형식은 Change_ID[<suffix>]입니다. 여기서 <suffix>는 테이블에 Change_ID 열이 이미 있는 경우에 선택적으로 추가됩니다.

  • 시스템 버전 관리 메모리 최적화 테이블에 대한 최대 행 크기는 준비 테이블의 추가 bigint 열 때문에 8 바이트만큼 감소합니다. 새 최대값은 이제 8,052 바이트입니다.

  • 내부 메모리 최적화 준비 테이블은 SQL Server Management Studio의 개체 탐색기에 표시되지 않습니다.

  • 이 테이블에 관한 메타데이터와 현재 temporal 테이블과의 연결도 sys.internal_tables에서 찾을 수 있습니다.

데이터 플러시 작업

데이터 플러시는 메모리 최적화 테이블이 메모리 크기 기반 데이터 이동 조건을 만족하는지 여부를 검사하는 정기적으로 활성화되는 태스크입니다. 데이터 이동은 내부 준비 테이블의 메모리 소비량이 현재 temporal 테이블의 메모리 소비량의 8%에 도달할 때 시작됩니다.

데이터 플러시 작업은 기존 작업을 기반으로 변화하는 일정을 사용하여 정기적으로 활성화됩니다. 워크로드가 많으면 작업이 5초마다 실행됩니다. 워크로드가 적으면 빈도는 1분까지 증가합니다. 정리가 필요한 각 내부 메모리 최적화 준비 테이블에 대해 스레드 한 개가 생성됩니다.

데이터 플러시는 현재 실행 중인 가장 오래된 트랜잭션보다 더 오래된 메모리 내 내부 버퍼의 모든 레코드를 삭제하여 이러한 레코드를 디스크 기반 기록 테이블로 이동합니다.

sp_xtp_flush_temporal_history를 실행하고 스키마와 테이블 이름을 지정하여 데이터 플러시를 실행할 수 있습니다.

EXEC sys.sp_xtp_flush_temporal_history <schema_name>, <object_name>;

내부 일정에 따라 시스템에 의해 데이터 플러시 태스크를 호출할 때와 같은 데이터 이동 프로세스가 호출됩니다.