메모리 최적화 테이블의 스토리지 구성
적용 대상: 
SQL Server
스토리지 용량 및 IOPS(초당 입력/출력 작업)를 구성해야 합니다.
스토리지 용량
메모리 최적화 테이블에 대한 메모리 요구 사항 예측의 정보를 사용하여 데이터베이스의 지속형 메모리 최적화 테이블의 메모리 내 크기를 예측합니다. 인덱스는 메모리 최적화 테이블에 대해 유지되지 않으므로 인덱스의 크기를 포함하지 않습니다.
크기를 확인한 후에는 새로 변경된 데이터를 저장하는 데 사용되는 검사점 파일을 보관할 수 있는 충분한 디스크 공간을 제공해야 합니다. 저장된 데이터에는 메모리 내 테이블에 추가되는 새 행의 내용뿐만 아니라 기존 행의 새 버전도 포함됩니다. 이 스토리지는 행을 삽입하거나 업데이트할 때 증가합니다. 행 버전은 병합되고 로그 잘림이 발생하면 스토리지가 회수됩니다. 어떤 이유로든 로그 잘림이 지연되면 메모리 내 OLTP 저장소가 늘어납니다.
이 영역에 대한 스토리지 크기를 조정하는 좋은 시작점은 내구성이 있는 메모리 내 테이블 크기의 4배를 예약하는 것입니다. 공간 사용량을 모니터링하고 필요한 경우 사용 가능한 스토리지를 확장할 수 있도록 준비합니다.
스토리지 IOPS
메모리 내 OLTP는 워크로드 처리량을 크게 늘릴 수 있습니다. 따라서 IO가 병목 상태가 아닌지 확인하는 것이 중요합니다.
디스크 기반 테이블을 메모리 최적화 테이블로 마이그레이션할 때 트랜잭션 로그가 증가된 트랜잭션 로그 작업을 지원할 수 있는 스토리지 미디어에 있는지 확인합니다. 예를 들어 스토리지 미디어가 100MB/초로 트랜잭션 로그 작업을 지원하고 메모리 최적화 테이블이 5배 뛰어난 성능을 발휘하는 경우 트랜잭션 로그의 스토리지 미디어는 트랜잭션 로그 작업에 성능 병목 상태가 발생하지 않도록 5배의 성능 향상을 지원할 수 있어야 합니다.
메모리 최적화 테이블은 하나 이상의 컨테이너 간에 분산된 검사점 파일에서 유지됩니다. 각 컨테이너는 일반적으로 자체 스토리지 디바이스에 매핑되어야 하며 스토리지 용량 증가 및 향상된 IOPS에 모두 사용됩니다. 스토리지 미디어의 순차 IOPS가 지속적인 트랜잭션 로그 처리량의 최대 3배까지 지원할 수 있는지 확인해야 합니다. 검사점 파일에 대한 쓰기는 데이터 파일의 경우 256KB, 델타 파일의 경우 4KB입니다.
- 예를 들어 메모리 최적화 테이블이 트랜잭션 로그에서 500MB/초의 작업을 생성하는 경우 메모리 최적화 테이블의 스토리지는 1.5GB/초 IOPS를 지원해야 합니다. 유지 가능한 트랜잭션 로그 처리량 3배 지원 요구는 데이터 및 델타 파일 쌍을 초기 데이터에 먼저 쓴 다음 병합 작업의 일부로 읽거나 다시 써야 하는 과정에서 발생합니다.
스토리지에 대한 IOPS를 예측하는 또 다른 요인은 메모리 최적화 테이블의 복구 시간입니다. 애플리케이션에서 데이터베이스를 사용할 수 있게 하려면 먼저 지속형 테이블의 데이터를 메모리로 읽어야 합니다. 일반적으로 메모리 최적화 테이블로 데이터 로드는 IOPS의 속도로 수행할 수 있습니다. 따라서 지속형 메모리 최적화 테이블의 총 스토리지가 60GB이고 이 데이터를 1분 안에 로드하려면 스토리지에 대한 IOPS를 1GB/초로 설정해야 합니다.
일반적으로 검사점 파일은 공간이 허용된다면 모든 컨테이너 간에 균일하게 분산됩니다. SQL Server 2014를 사용하면 균일한 배포를 달성하기 위해 홀수의 컨테이너를 프로비전해야 합니다. 2016년부터는 홀수와 짝수의 컨테이너가 모두 균일한 배포로 이어지게 됩니다.
암호화
SQL Server 2016 (13.x) 이상 버전에서는 메모리 최적화 테이블의 스토리지가 데이터베이스에서 TDE(투명한 데이터 암호화)를 사용하도록 설정하는 과정에서 미사용 시 암호화됩니다. 자세한 내용은 투명한 데이터 암호화를 참조하세요. 데이터베이스에서 TDE를 사용하도록 설정한 경우에도 SQL Server 2014(12.x) 검사점 파일은 암호화되지 않습니다.
비지속형(SCHEMA_ONLY) 메모리 최적화 테이블의 데이터는 언제든지 디스크에 기록되지 않습니다. 따라서 TDE는 이러한 테이블에 적용되지 않습니다.