적용 대상:
SQL Server 2016(13.x) 이상 버전 Azure SQL Managed Instance
메모리 최적화 테이블을 위한 시스템 버전 시간 테이블은 인메모리 OLTP 워크로드로 수집된 데이터 위에 데이터 감사와 시점 분석이 필요한 시나리오에서 비용 효율적인 솔루션을 제공합니다.
메모
메모리 최적화 임시 테이블은 SQL Server 및 Azure SQL Managed Instance에서만 사용할 수 있습니다. 메모리 최적화 테이블 및 임시 테이블은 Azure SQL Database에서 독립적으로 사용할 수 있습니다.
Overview
시스템 버전 관리 temporal 테이블은 자동으로 데이터 변경 내용에 대한 전체 기록을 유지하며 특정 시간 분석에 대해 편리한 TRANSACT-SQL 확장을 적용합니다. 일반적인 시나리오에서는 데이터 이력이 오랜 기간 (수개월, 심지어 몇 년) 유지되며, 정기적으로 조회되지 않더라도 마찬가지입니다.
데이터 감사와 시간 기반 분석은 특히 매우 많은 요청을 처리하는 OLTP 시스템과 인메모리 OLTP 기술이 사용되는 환경에서 요구될 수 있습니다. 그러나 메모리 최적화 테이블을 temporal 시나리오에 사용하는 것은 일반적으로 막대한 양의 기록 데이터가 생성되어 사용 가능 RAM의 한계를 초과하기 때문에 어려울 수 있습니다. 동시에 자주 액세스하지 않아서 오래된 읽기 전용 기록 데이터를 RAM에 저장하는 것은 최적의 솔루션이 아닙니다.
메모리 최적화 테이블을 위한 시스템 버전 버전 시간 테이블은 높은 트랜잭션 처리량과 잠금 없는 동시성을 제공합니다. 현재 데이터를 저장할 때는 인메모리 테이블(temporal table)을, 디스크 기반 테이블을 사용해 히스토리 데이터를 저장할 수 있습니다. 최근 기록을 저장하고 네이티브 컴파일 코드에서 DML을 실행할 수 있게 하는 내부적으로 자동 생성된 메모리 최적화 준비 테이블을 사용하면 DML 작업에 미치는 영향을 줄일 수 있습니다.
다음 다이어그램은 이 아키텍처를 보여 줍니다.
구현 세부 정보
시스템 버전이 지정된 메모리 최적화 테이블을 만들 때는 다음 사항에 유의하세요. 구문 옵션 및 예제는 다음을 참조하세요 CREATE TABLE.
내구성 있는 메모리 최적화 테이블만이 시스템 버전 관리가 가능합니다(
DURABILITY = SCHEMA_AND_DATA).메모리 최적화 시스템 버전 관리 테이블의 히스토리 테이블은 반드시 디스크 기반이어야 하며, 사용자가 생성하든 시스템이 생성하든 마찬가지입니다.
네이티브로 컴파일된 T-SQL 모듈에서는 현재 인메모리 테이블에만 영향을 미치는 쿼리를 사용할 수 있습니다. 네이티브로 컴파일된 모듈은
FOR SYSTEM TIME절을 지원하지 않지만, 애드혹 쿼리와 네이티브가 아닌 모듈은 메모리 최적화 테이블에서 이 절을 사용할 수 있습니다.이 있을 때
SYSTEM_VERSIONING = ON, 시스템은 최신 메모리 최적화 테이블의 업데이트 및 삭제 작업으로 인해 발생한 최신 시스템 버전 변경 사항을 수용하기 위해 내부 메모리 최적화 스테이징 테이블을 자동으로 생성합니다.비동기 데이터 플러시 작업은 정기적으로 내부 메모리 최적화 스테이징 테이블에서 디스크 기반 히스토리 테이블로 데이터를 이동시킵니다. 이 데이터 플러시 메커니즘의 목표는 내부 메모리 버퍼를 상위 개체의 메모리 소비량의 10% 미만으로 유지하는 것입니다. 메모리 최적화 시스템 버전 시간 테이블의 총 메모리 소비량을 sys.dm_db_xtp_memory_consumers 쿼리하고 내부 메모리 최적화 스테이징 테이블과 현재 시간 테이블의 데이터를 요약하여 추적할 수 있습니다.
수동으로 데이터 플러시를 하려면 sp_xtp_flush_temporal_history 실행하는 것입니다.
SYSTEM_VERSIONING = OFF이거나, 열을 추가, 삭제 또는 변경하여 시스템 버전 관리 테이블의 스키마를 수정하면 내부 스테이징 버퍼의 전체 내용이 디스크 기반 기록 테이블로 이동합니다.기록 데이터 쿼리는 결과적으로 스냅샷 격리 수준 아래에 있으며 언제나 메모리 내 준비 버퍼와 디스크 기반 테이블 사이의 합집합을 중복 없이 반환합니다.
ALTER TABLE내부적으로 테이블 스키마를 변경하는 작업은 데이터 플러시를 수행해야 하며, 이로 인해 작업이 길어질 수 있습니다.
내부 메모리 최적화 스테이징 테이블
시스템은 내부 메모리 최적화 준비 테이블을 만들어 DML 작업을 최적화합니다.
테이블 이름은 다음과 같은 형식을 사용합니다:
Memory_Optimized_History_Table_<object_id>여기서<object_id>는 현재 시간 테이블의 식별자입니다.이 테이블은 현재 시간 테이블의 스키마와 하나의 bigint 컬럼을 복제합니다. 이 추가 열은 내부 히스토리 버퍼로 이동된 행의 유일성을 보장합니다.
추가 열 이름의 형식은
Change_ID[<suffix>]입니다. 여기서<suffix>는 테이블에Change_ID열이 이미 있는 경우에 선택적으로 추가됩니다.시스템 버전 관리형 메모리 최적화 테이블의 최대 행 크기는 스테이징 테이블에 추가 bigint 열이 있기 때문에 8바이트만큼 줄어듭니다. 최대 용량은 현재 8,052바이트입니다.
내부 메모리 최적화 스테이징 테이블은 SQL Server Management Studio의 개체 탐색기에 나타나지 않습니다.
이 테이블과 현재 시간 테이블과의 연결에 관한 메타데이터는 sys.internal_tables에서 찾을 수 있습니다.
데이터 플러시 작업
데이터 플러시 작업은 정기적으로 실행되며, 메모리 최적화 테이블이 데이터 이동에 대한 메모리 크기 기반 조건을 충족하는지 확인합니다. 데이터 이동은 내부 스테이징 테이블의 메모리 소비가 현재 시간 테이블의 메모리 소비량의 8%에 도달할 때 시작됩니다.
데이터 플러시 작업은 기존 작업을 기반으로 변화하는 일정을 사용하여 정기적으로 활성화됩니다. 워크로드가 많으면 작업이 5초마다 실행됩니다. 워크로드가 적으면 빈도는 1분까지 증가합니다. 정리가 필요한 각 내부 메모리 최적화 준비 테이블에 대해 스레드 한 개가 생성됩니다.
데이터 플러시는 현재 실행 중인 가장 오래된 트랜잭션보다 더 오래된 메모리 내 내부 버퍼의 모든 레코드를 삭제하여 이러한 레코드를 디스크 기반 기록 테이블로 이동합니다.
sp_xtp_flush_temporal_history를 실행하고 스키마와 테이블 이름을 지정하여 데이터 플러시를 실행할 수 있습니다.
EXEC sys.sp_xtp_flush_temporal_history <schema_name>, <object_name>;
내부 일정에 따라 시스템에 의해 데이터 플러시 태스크를 호출할 때와 같은 데이터 이동 프로세스가 호출됩니다.