SQL Server에 메모리 내 OLTP 기능 채택 계획
적용 대상: 
SQL Server Azure SQL 데이터베이스 Azure SQL Managed Instance
이 문서에서는 SQL Server의 메모리 내 기능 채택이 비즈니스 시스템의 다른 측면에 영향을 미치는 방식을 설명합니다.
참고 항목
- Azure SQL 데이터베이스의 메모리 내 데이터와 관련된 자세한 내용은 Azure SQL 데이터베이스에서 메모리 내 기술을 사용하여 성능 최적화, 블로그: Azure SQL 데이터베이스의 메모리 내 OLTP를 참조하세요.
- Azure SQL Managed Instance의 메모리 내 데이터와 관련된 자세한 내용은 Azure SQL Managed Instance에서 메모리 내 기술을 사용하여 성능 최적화를 참조하세요.
A. 메모리 내 OLTP 기능 채택
다음 하위 섹션에서는 메모리 내 기능을 채택하고 구현하려는 경우 고려해야 할 요소를 설명합니다.
A.1 필수 구성 요소
메모리 내 기능을 사용하기 위한 한 가지 필수 구성 요소에는 SQL 제품의 버전 또는 서비스 계층이 포함될 수 있습니다. 이 구성 요소와 기타 필수 구성 요소는 다음을 참조하세요.
A.2 활성 메모리 양 예측
시스템에 새 메모리 최적화 테이블을 지원하기에 충분한 활성 메모리가 있나요?
Microsoft SQL Server
200GB의 데이터를 포함하는 메모리 최적화 테이블에는 200GB 이상의 활성 메모리가 지원 전용이어야 합니다. 많은 양의 데이터를 포함하는 메모리 최적화 테이블을 구현하기 전에 서버 컴퓨터에 추가해야 할 수 있는 추가 활성 메모리의 양을 예측해야 합니다. 예측 지침은 다음을 참조하세요.
Azure SQL Managed Instance에도 비슷한 지침이 제공됩니다.
Azure SQL Database
Azure SQL Database 클라우드 서비스에 호스트된 데이터베이스의 경우 선택한 서비스 계층이 데이터베이스에서 사용할 수 있는 활성 메모리의 양에 영향을 줍니다. 경고를 사용하여 데이터베이스의 메모리 사용량 모니터링을 계획해야 합니다. 자세한 내용은 다음을 참조하세요.
- 가격 책정 계층에 대한 메모리 내 OLTP 스토리지 제한 검토
- Azure SQL 데이터베이스에서 메모리 내 OLTP 스토리지 모니터링
메모리 최적화 테이블 변수
메모리 최적화로 선언된 테이블 변수는 tempdb 데이터베이스에 있는 기존 #TempTable에서 선호되는 경우가 있습니다. 테이블 변수는 상당한 양의 활성 메모리를 사용하지 않고도 성능 향상을 제공할 수 있습니다.
A.3 메모리 최적화로 변환하려면 테이블이 오프라인이어야 함
일부 ALTER TABLE 기능은 메모리 최적화 테이블에 사용할 수 있습니다. 그러나 디스크 기반 테이블을 메모리 최적화 테이블로 변환하기 위해 ALTER TABLE 문을 실행할 수는 없습니다. 대신 더 많은 일련의 수동 단계를 사용해야 합니다. 다음은 디스크 기반 테이블을 메모리 최적화로 변환하는 다양한 방법입니다.
수동 스크립팅
디스크 기반 테이블을 메모리 최적화 테이블로 변환하는 한 가지 방법은 필요한 TRANSACT-SQL 단계를 직접 코딩하는 것입니다.
애플리케이션 활동을 일시 중단합니다.
전체 백업을 수행합니다.
디스크 기반 테이블의 이름을 바꿉니다.
CREATE TABLE 문을 실행하여 새 메모리 최적화 테이블을 만듭니다.
디스크 기반 테이블의 하위 SELECT를 사용하여 메모리 최적화 테이블에 삽입합니다.
디스크 기반 테이블을 삭제합니다.
또 다른 전체 백업을 수행합니다.
애플리케이션 활동을 다시 시작합니다.
메모리 최적화 관리자
메모리 최적화 관리자 도구는 디스크 기반 테이블을 메모리 최적화 테이블로 변환하는 데 도움이 되는 스크립트를 생성할 수 있습니다. 이 도구는 SSDT(SQL Server Data Tools)의 일부로 설치됩니다.
.dacpac 파일
SSDT에서 관리하는 .dacpac 파일을 사용하여 데이터베이스를 현재 위치에서 업데이트할 수 있습니다. SSDT에서 .dacpac 파일에 인코딩된 스키마에 대한 변경 내용을 지정할 수 있습니다.
데이터베이스형식의 Visual Studio 프로젝트 컨텍스트에서 .dacpac 파일을 사용합니다.
- 데이터 계층 애플리케이션 및 .dacpac 파일
A.4 메모리 내 OLTP 기능이 애플리케이션에 적합한지 여부에 대한 지침
메모리 내 OLTP 기능이 특정 애플리케이션의 성능을 향상시킬 수 있는지 여부에 대한 지침은 다음을 참조하세요
B. 지원되지 않는 기능
특정 메모리 내 OLTP 시나리오에서 지원되지 않는 기능은 다음에 설명되어 있습니다.
다음 하위 섹션에서는 지원되지 않는 더 중요한 기능 중 일부를 강조 표시합니다.
B.1 데이터베이스 스냅샷
지정된 데이터베이스에서 처음으로 메모리 최적화 테이블 또는 모듈이 만들어진 후에는 데이터베이스의 스냅샷 을 생성할 수 없습니다. 구체적인 이유는 다음과 같습니다.
- 첫 번째 메모리 최적화 항목을 사용하면 메모리 최적화 파일 그룹에서 마지막 파일을 삭제할 수 없습니다. 그리고
- 메모리 최적화 파일 그룹에 파일이 있는 데이터베이스는스냅샷을 지원할 수 없습니다.
일반적으로 스냅샷은 빠른 테스트 반복에 유용합니다.
B.2 데이터베이스 간 쿼리
메모리 액세스에 최적화된 테이블은 데이터베이스 간 트랜잭션을 지원하지 않습니다. 메모리 최적화 테이블에도 액세스하는 동일한 쿼리 또는 동일한 트랜잭션에서 다른 데이터베이스에 액세스할 수 없습니다.
테이블 변수는 트랜잭션이 아닙니다. 따라서 데이터베이스 간 쿼리에서 메모리 최적화 테이블 변수를 사용할 수 있습니다.
B.3 READPAST 테이블 힌트
메모리 최적화 테이블에 READPAST 테이블 힌트를 적용할 수 있는 쿼리는 없습니다.
READPAST 힌트는 큐 처리와 같이 여러 세션이 각각 동일한 작은 행 집합에 액세스하고 수정하는 시나리오에서 유용합니다.
B.4 RowVersion, Sequence
메모리 최적화 테이블에서 RowVersion에 대해 열에 태그를 지정할 수 없습니다.
메모리 최적화 테이블의 제약 조건과 함께 SEQUENCE를 사용할 수 없습니다. 예를 들어 NEXT VALUE FOR 절에 DEFAULT 제약 조건을 만들 수 없습니다. SEQUENCE는 INSERT 및 UPDATE 문과 함께 사용할 수 있습니다.
C. 관리 및 유지 관리
이 섹션에서는 메모리 최적화 테이블을 사용하는 데이터베이스 관리의 차이점을 설명합니다.
C.1 ID 시드 초기화, > 1 증가
메모리 최적화 테이블에는 IDENTITY 열을 재설정하는DBCC CHECKIDENT를 사용할 수 없습니다.
메모리 최적화 테이블에서는 IDENTITY 열의 증분 값이 정확히 1로 제한됩니다.
C.2 DBCC CHECKDB는 메모리 최적화 테이블의 유효성을 검사할 수 없음
대상이 메모리 최적화 테이블인 경우 DBCC CHECKDB 명령은 아무 작업도 수행하지 않습니다. 다음 단계는 해결 방법입니다.
트랜잭션 로그를 백업합니다.
메모리 최적화 파일 그룹의 파일을 null 디바이스에 백업합니다. 백업 프로세스에서는 체크섬 유효성 검사를 호출합니다.
손상이 발견되면 다음 단계를 진행합니다.
임시 스토리지 용도로, 메모리 최적화 테이블의 데이터를 디스크 기반 테이블에 복사합니다.
메모리 최적화 파일 그룹의 파일을 복원합니다.
디스크 기반 테이블에 임시로 저장된 데이터를 메모리 최적화 테이블에 삽입(INSERT INTO)합니다.
임시로 데이터를 저장한 디스크 기반 테이블을 삭제합니다.
D. 성능
이 섹션에서는 메모리 최적화 테이블의 뛰어난 성능을 최대한 보유할 수 있는 상황을 설명합니다.
D.1 인덱스 고려 사항
메모리 최적화 테이블의 모든 인덱스는 테이블 관련 문 CREATE TABLE 및 ALTER TABLE로 만들어지고 관리됩니다. CREATE INDEX 문을 사용하여 메모리 최적화 테이블을 대상으로 지정할 수 없습니다.
기존 B-트리 비클러스터형 인덱스는 메모리 최적화 테이블을 처음 구현할 때 합리적이고 간단한 선택인 경우가 많습니다. 나중에 애플리케이션의 성능을 확인한 후 다른 인덱스 유형으로 바꾸는 것을 고려할 수 있습니다.
참고 항목
설명서는 인덱스를 지칭할 때 B-트리라는 용어를 사용합니다. rowstore 인덱스에서 데이터베이스 엔진은 B+ 트리를 구현합니다. 이는 columnstore 인덱스나 메모리 최적화 테이블 인덱스에는 적용되지 않습니다. 자세한 내용은 SQL Server 및 Azure SQL 인덱스 아키텍처 및 디자인 가이드를 참조하세요.
메모리 최적화 테이블의 컨텍스트에서는 해시 인덱스 및 Columnstore 인덱스라는 두 가지 특수한 유형의 인덱스에 대한 논의가 필요합니다.
메모리 최적화 테이블의 인덱스에 대한 개요는 다음을 참조하세요.
해시 인덱스
해시 인덱스는 '=' 연산자를 사용하여 정확한 기본 키 값으로 특정 행에 액세스하는 가장 빠른 형식일 수 있습니다.
'!=', '>' 또는 'BETWEEN'과 같은 부정확한 연산자를 해시 인덱스와 함께 사용할 경우 성능이 저하됩니다.
해시 인덱스는 키 값 중복 비율이 너무 높은 경우에는 최선의 선택이 아닐 수도 있습니다.
개별 버킷 내에서 긴 체인을 방지하기 위해 해시 인덱스에 필요한 버킷 수를 과소 평가하지 않도록 합니다. 자세한 내용은 다음을 참조하세요.
비클러스터형 columnstore 인덱스
메모리 액세스에 최적화된 테이블은 온라인 트랜잭션 처리 또는 OLTP라고 하는 패러다임에서 일반적인 비즈니스 트랜잭션 데이터의 많은 처리량을 제공합니다. Columnstore 인덱스는 집계의 높은 처리량과 Analytics라고 하는 유사한 처리를 제공합니다. 지난 수년간 OLTP와 분석 둘 다의 요구 사항을 만족하는 데 사용할 수 있는 최고의 접근 방식은 데이터 이동이 많고 어느 정도의 데이터 중복도가 있는 별도의 테이블을 사용하는 것이었습니다. 이제 더 간단한 하이브리드 솔루션을 사용할 수 있습니다. 메모리 최적화 테이블에 columnstore 인덱스를 사용합니다.
columnstore 인덱스가 클러스터형 인덱스인 경우에도 디스크 기반 테이블에 빌드할 수 있습니다. 그러나 메모리 최적화 테이블에서 columnstore 인덱스는 클러스터될 수 없습니다.
메모리 최적화 테이블에 대한 LOB 또는 행이 다른 열은 테이블에 columnstore 인덱스를 만들지 못하게 합니다.
테이블에 columnstore 인덱스가 있는 동안에는 메모리 최적화 테이블에 대해 ALTER TABLE 문을 실행할 수 없습니다.
- 2016년 8월 현재 Microsoft는 가까운 시일 내 columnstore 인덱스 다시 만들기 성능을 향상하기 위한 계획이 있습니다.
D.2 LOB 및 행이 다른 열
LOB(Large Object)는varchar(max) 형식의 열입니다. 메모리 최적화 테이블에 LOB 열이 몇 개 있으면 성능에 중요한 영향을 미치지 않습니다. 그러나 데이터에 필요한 것보다 많은 LOB 열은 사용하지 않도록 합니다. 행이 다른 열에 동일한 조언이 적용됩니다. varchar(512)가 충분하면 열을 nvarchar(3072)로 정의하지 마세요.
LOB 및 행이 다른 열에 대한 자세한 내용은 다음에서 확인할 수 있습니다.
E. 네이티브 프로시저의 제한 사항
Transact-SQL의 특정 요소는 저장 프로시저를 포함하여 네이티브 컴파일된 T-SQL 모듈에서 지원되지 않습니다. 지원되는 기능에 대한 자세한 내용은 다음을 참조하세요.
지원되지 않는 기능을 사용하여 네이티브 컴파일된 Transact-SQL 모듈을 마이그레이션할 때 고려해야 할 사항은 다음을 참조하세요.
Transact-SQL의 특정 요소에 대한 제한 사항 외에도 네이티브 컴파일된 T-SQL 모듈에서 지원되는 쿼리 연산자에도 제한이 있습니다. 이러한 제한 사항 때문에 고유하게 컴파일된 저장 프로시저는 큰 데이터 집합을 처리하는 분석 쿼리에는 적합하지 않습니다.
네이티브 프로시저에서 병렬 처리 없음
병렬 처리는 네이티브 프로시저에 대한 쿼리 계획의 일부가 될 수 없습니다. 네이티브 프로시저는 항상 단일 스레드입니다.
조인 유형
해시 조인과 병합 조인은 모두 네이티브 프로시저에 대한 쿼리 계획의 일부가 될 수 없습니다. 중첩 루프 조인이 사용됩니다.
해시 집계 없음
네이티브 프로시저에 대한 쿼리 계획에 집계 단계가 필요한 경우 스트림 집계만 사용할 수 있습니다. 네이티브 프로시저에 대한 쿼리 계획에서는 해시 집계가 지원되지 않습니다.
- 많은 수의 행에서 데이터를 집계해야 하는 경우 해시 집계가 낫습니다.
F. 애플리케이션 디자인: 트랜잭션 및 재시도 논리
메모리 최적화 테이블과 관련된 트랜잭션은 동일한 테이블을 포함하는 다른 트랜잭션에 종속될 수 있습니다. 종속 트랜잭션 수가 허용되는 최대값에 도달하면 모든 종속 트랜잭션이 실패합니다.
SQL Server 2016:
- 허용되는 최대값은 8개의 종속 트랜잭션입니다. 8은 지정된 트랜잭션이 종속될 수 있는 트랜잭션의 제한이기도 합니다.
- 오류 번호는 41839입니다. (SQL Server 2014에서 오류 번호는 41301입니다.)
스크립트에 재시도 논리 를 추가하여 Transact-SQL 스크립트를 가능한 트랜잭션 오류에 대해 더 강력하게 만들 수 있습니다. 재시도 논리는 UPDATE 및 DELETE 호출이 빈번하거나 다른 테이블의 외래 키가 메모리 최적화 테이블을 참조하는 경우 더 유용할 수 있습니다. 자세한 내용은 다음을 참조하세요.