In-Memory OLTP는 메모리 최적화 테이블에 대한 전체 내구성을 제공합니다. 메모리 최적화 테이블을 변경한 트랜잭션이 커밋되면 SQL Server(디스크 기반 테이블의 경우처럼)는 기본 스토리지를 사용할 수 있는 경우 변경 내용이 영구(데이터베이스 다시 시작 시 유지됨)되도록 보장합니다. 내구성에는 트랜잭션 로깅과 디스크 내 스토리지에 대한 데이터 변경 내용 유지의 두 가지 주요 구성 요소가 있습니다.
트랜잭션 로그
디스크 기반 테이블 또는 지속성 메모리 최적화 테이블에 대한 모든 변경 내용은 하나 이상의 트랜잭션 로그 레코드에 캡처됩니다. 트랜잭션이 커밋되면 SQL Server는 트랜잭션이 커밋한 애플리케이션 또는 사용자 세션에 통신하기 전에 트랜잭션과 연결된 로그 레코드를 디스크에 씁니다. 이렇게 하면 트랜잭션이 변경한 내용이 지속됩니다. 메모리 최적화 테이블의 트랜잭션 로그는 디스크 기반 테이블에서 사용하는 것과 동일한 로그 스트림과 완전히 통합됩니다. 이 통합을 사용하면 추가 단계 없이 기존 트랜잭션 로그 백업, 복구 및 복원 작업이 계속 작동할 수 있습니다. 그러나 In-Memory OLTP는 워크로드의 트랜잭션 처리량을 크게 증가시킬 수 있으므로 증가된 IO 요구 사항을 처리하도록 트랜잭션 로그 스토리지가 적절하게 구성되었는지 확인해야 합니다.
데이터 및 델타 파일
메모리 최적화 테이블의 데이터는 메모리에 하나 이상의 메모리 내 인덱스를 통해 연결된 자유 형식 데이터 행으로 저장됩니다. 디스크 기반 테이블에 사용되는 것과 같은 데이터 행에 대한 페이지 구조는 없습니다. 애플리케이션이 트랜잭션을 커밋할 준비가 되면 In-Memory OLTP는 트랜잭션에 대한 로그 레코드를 생성합니다. 메모리 최적화 테이블의 지속성은 백그라운드 스레드를 사용하여 데이터 및 델타 파일 집합으로 수행됩니다. 데이터 및 델타 파일은 하나 이상의 컨테이너에 있습니다(FILESTREAM 데이터에 사용되는 것과 동일한 메커니즘 사용). 이러한 컨테이너는 메모리 최적화 파일 그룹이라고 하는 새 형식의 파일 그룹에 매핑됩니다.
데이터는 엄격하게 순차적으로 이러한 파일에 기록되므로 회전하는 미디어의 디스크 대기 시간을 최소화할 수 있습니다. 여러 디스크의 여러 컨테이너를 사용하여 I/O 작업을 배포할 수 있습니다. 서로 다른 디스크의 여러 컨테이너에 있는 데이터 및 델타 파일은 디스크의 데이터 및 델타 파일에서 메모리로 데이터를 읽을 때 복구 성능을 향상합니다.
애플리케이션은 데이터 및 델타 파일에 직접 액세스하지 않습니다. 모든 데이터 읽기 및 쓰기는 메모리 내 데이터를 사용합니다.
데이터 파일
데이터 파일에는 INSERT 또는 UPDATE 작업의 일부로 여러 트랜잭션에 의해 삽입된 하나 이상의 메모리 최적화 테이블의 행이 포함되어 있습니다. 예를 들어 한 행은 메모리 최적화 테이블 T1에서, 다음 행은 메모리 최적화 테이블 T2에서 사용할 수 있습니다. 행은 트랜잭션 로그의 트랜잭션 순서대로 데이터 파일에 추가되어 데이터 액세스가 순차적으로 만들어집니다. 이렇게 하면 임의 I/O에 비해 성능이 큰 폭으로 향상된 I/O 처리량을 사용할 수 있습니다. 각 데이터 파일의 크기는 메모리가 16GB보다 큰 컴퓨터의 경우 약 128MB, 16GB보다 작거나 같은 컴퓨터의 경우 16MB입니다. 데이터 파일이 가득 차면 새 트랜잭션에 의해 삽입된 행이 다른 데이터 파일에 저장됩니다. 시간이 지나면, 지속성 메모리 최적화 테이블의 행은 여러 데이터 파일에 저장됩니다. 각 데이터 파일은 서로 구분되지만 연속적인 트랜잭션 범위의 행을 포함합니다. 예를 들어(100, 200) 범위의 트랜잭션 커밋 타임스탬프가 있는 데이터 파일에는 커밋 타임스탬프가 100보다 크고 200보다 작거나 같은 트랜잭션에 의해 삽입된 모든 행이 있습니다. 커밋 타임스탬프는 커밋할 준비가 되면 트랜잭션에 할당된 일체적으로 증가하는 수입니다. 각 트랜잭션에는 고유한 커밋 타임스탬프가 있습니다.
행이 삭제되거나 업데이트되면 데이터 파일에서 행이 제거되거나 변경되지 않지만 삭제된 행은 다른 형식의 파일인 델타 파일에서 추적됩니다. 업데이트 작업은 각 행에 대한 삭제 및 삽입 작업의 튜플로 처리됩니다. 이렇게 하면 데이터 파일의 임의 IO가 제거됩니다.
델타 파일
각 데이터 파일은 트랜잭션 범위가 동일한 델타 파일과 쌍을 이루며 트랜잭션 범위의 트랜잭션에 의해 삽입된 삭제된 행을 추적합니다. CFP(검사점 파일 쌍)는 할당 및 해제의 단위일 뿐만 아니라 병합 작업의 단위로서 참조되는 데이터 및 델타 파일입니다. 예를 들어, 트랜잭션 범위(100, 200)에 해당하는 델타 파일은 범위(100, 200)의 트랜잭션에 의해 삽입되었던 삭제된 행을 저장하게 됩니다. 데이터 파일과 마찬가지로 델타 파일은 순차적으로 액세스됩니다.
행이 삭제되면 행은 데이터 파일에서 제거되지 않지만 이 데이터 행이 삽입된 트랜잭션 범위와 연결된 델타 파일에 행에 대한 참조가 추가됩니다. 삭제할 행이 데이터 파일에 이미 있으므로 델타 파일은 참조 정보 {inserting_tx_id, row_id, deleting_tx_id } 만 저장하고 원래 삭제 또는 업데이트 작업의 트랜잭션 로그 순서를 따릅니다.
데이터 및 델타 파일 채우기
데이터 및 델타 파일은 오프라인 검사점이라는 백그라운드 스레드에 의해 채워집니다. 이 스레드는 메모리 최적화 테이블에서 커밋된 트랜잭션에 의해 생성된 트랜잭션 로그 레코드를 읽고 삽입 및 삭제된 행에 대한 정보를 적절한 데이터 및 델타 파일에 추가합니다. 검사점이 완료되면 데이터/인덱스 페이지가 임의 I/O로 플러시되는 디스크 기반 테이블과 달리 메모리 최적화 테이블의 지속성은 연속 백그라운드 작업입니다. 트랜잭션이 이전 트랜잭션에서 삽입한 행을 삭제하거나 업데이트할 수 있으므로 여러 델타 파일에 액세스합니다. 삭제 정보는 항상 델타 파일의 끝에 추가됩니다. 예를 들어 커밋 타임스탬프가 600인 트랜잭션은 새 행 하나를 삽입하고 아래 그림과 같이 커밋 타임스탬프가 150, 250 및 450인 트랜잭션에 의해 삽입된 행을 삭제합니다. 4개의 파일 I/O 작업(삭제된 행의 경우 3개, 새로 삽입된 행의 경우 1개)은 해당 델타 및 데이터 파일에 추가 전용 작업입니다.
데이터 및 델타 파일 액세스
데이터 및 델타 파일 쌍은 다음이 발생할 때 액세스됩니다.
오프라인 체크포인트 스레드 이 스레드는 메모리 최적화된 데이터 행에 대한 삽입 및 삭제를 해당 데이터 및 델타 파일 쌍에 추가합니다.
병합 작업 작업 하나 이상의 데이터 및 델타 파일 쌍을 병합하고 새 데이터 및 델타 파일 쌍을 만듭니다.
크래시 복구 중에 SQL Server가 다시 시작되거나 데이터베이스가 다시 온라인 상태가 되면 데이터 및 델타 파일 쌍을 사용하여 메모리 최적화 데이터가 채워집니다. 델타 파일은 해당 데이터 파일에서 행을 읽을 때 삭제된 행에 대한 필터 역할을 합니다. 각 데이터와 델타 파일 쌍은 독립적이므로 이러한 파일은 메모리에 데이터를 채우는 데 걸리는 시간을 줄이기 위해 병렬로 로드됩니다. 데이터가 메모리에 로드되면 In-Memory OLTP 엔진은 메모리 최적화 데이터가 완료되도록 검사점 파일에서 아직 다루지 않는 활성 트랜잭션 로그 레코드를 적용합니다.
복원 작업 중 In-Memory OLTP 검사점 파일이 데이터베이스 백업에서 생성되고 하나 이상의 트랜잭션 로그 백업이 적용됩니다. 크래시 복구와 마찬가지로 In-Memory OLTP 엔진은 복구 시간에 미치는 영향을 최소화하기 위해 데이터를 메모리에 병렬로 로드합니다.
데이터 및 델타 파일 병합
메모리 최적화 테이블의 데이터는 하나 이상의 데이터 및 델타 파일 쌍(검사점 파일 쌍 또는 CFP라고도 함)에 저장됩니다. 데이터 파일은 삽입된 행을 저장하고 델타 파일은 삭제된 행을 참조합니다. OLTP 워크로드를 실행하는 동안 DML 작업이 행을 업데이트, 삽입 및 삭제할 때 새 행을 유지하기 위해 새 CFP가 생성되고 삭제된 행에 대한 참조가 델타 파일에 추가됩니다.
이전에 닫힌 현재 활성 CFP의 메타데이터는 스토리지 배열이라고 하는 내부 배열 구조에 저장됩니다. CFP의 한정된 크기(8,192개 항목) 배열입니다. 스토리지 배열의 항목은 트랜잭션 범위별로 정렬됩니다. 스토리지 배열의 CFP(로그의 꼬리와 함께)는 메모리 최적화 테이블을 사용하여 데이터베이스를 복구하는 데 필요한 모든 디스크 상태를 나타냅니다.
시간이 지남에 따라 DML 작업을 통해 CFP 수가 증가하여 스토리지 배열이 용량에 도달하게 되며, 이로 인해 다음과 같은 문제가 발생합니다.
삭제된 행입니다. 삭제된 행은 데이터 파일에 남아 있지만 해당 델타 파일에서 삭제된 것으로 표시됩니다. 이러한 행은 더 이상 필요하지 않으며 스토리지에서 제거됩니다. 삭제된 행이 CFP에서 제거되지 않은 경우 불필요하게 공간을 사용하고 복구 시간을 느리게 만듭니다.
스토리지 배열이 가득 찼습니다. 스토리지 배열에 8,000개의 항목이 할당된 경우(배열의 192개 항목은 기존 병합이 경쟁하거나 수동 병합을 수행할 수 있도록 예약되어 있음) 지속성 메모리 최적화 테이블에서 새 DML 트랜잭션을 실행할 수 없습니다. 검사점 및 병합 작업만 나머지 항목을 사용하도록 허용됩니다. 이렇게 하면 DML 트랜잭션이 배열을 채우지 않고 배열의 일부 항목이 기존 파일을 병합하고 배열의 공간을 회수하기 위해 예약됩니다.
스토리지 배열 조작 오버헤드. 내부 프로세스는 삭제된 행에 대한 정보를 추가할 델타 파일 찾기와 같은 작업을 위해 스토리지 배열을 검색합니다. 이러한 작업의 비용은 항목 수에 따라 증가합니다.
이러한 비효율성을 방지하기 위해 아래에 설명된 병합 정책에 따라 이전의 닫힌 CFP가 병합되므로 스토리지 배열은 동일한 데이터 집합을 나타내도록 압축되고 CFP 수는 줄어듭니다.
데이터베이스의 모든 지속성 테이블의 총 메모리 내 크기는 250GB를 초과하면 안 됩니다. 최대 250GB의 메모리를 사용하는 지속성 테이블은 삽입, 삭제 및 업데이트 작업을 가정할 경우 평균 500GB의 스토리지 공간이 필요합니다. 500GB의 스토리지 공간을 지원하려면 메모리 최적화 파일 그룹의 4,000개 데이터 및 델타 파일 쌍이 필요합니다.
데이터베이스 작업의 단기 급증으로 인해 검사점 및 병합 작업이 지연되어 필요한 데이터 및 델타 파일 쌍의 수가 증가할 수 있습니다. 데이터베이스 작업의 단기 급증을 수용하기 위해 스토리지 시스템은 최대 8,000개의 데이터 및 델타 파일 쌍을 총 1TB의 스토리지에 할당할 수 있습니다. 이 제한에 도달하면 검사점 작업이 따라잡을 때까지 데이터베이스에서 허용되는 새 트랜잭션이 없습니다. 메모리의 지속성 테이블 크기가 오랜 시간 동안 250GB를 초과하는 경우 8,000개의 파일 쌍 제한에 도달할 가능성이 있습니다.
병합 작업은 내부적으로 정의된 병합 정책에 따라 하나 이상의 인접한 닫힌 CFP(병합 원본이라고 함)를 입력으로 사용하고 병합 대상이라고 하는 하나의 결과 CFP를 생성합니다. 원본 CFP의 각 델타 파일에 있는 항목은 해당 데이터 파일의 행을 필터링하여 필요하지 않은 데이터 행을 제거하는 데 사용됩니다. 원본 CFP의 나머지 행은 하나의 대상 CFP로 통합됩니다. 병합이 완료되면 결과 병합 대상 CFP가 원본 CFP(병합 원본)를 대체합니다. 병합 원본 CFP는 스토리지에서 제거되기 전에 전환 단계를 진행합니다.
아래 예제에서 메모리 최적화 테이블 파일 그룹에는 이전 트랜잭션의 데이터가 포함된 타임스탬프 500에 4개의 데이터 및 델타 파일 쌍이 있습니다. 예를 들어 첫 번째 데이터 파일의 행은 타임스탬프가 100보다 크고 200보다 작거나 같은 트랜잭션에 해당합니다. 또는 (100, 200]으로 표시됩니다. 두 번째 및 세 번째 데이터 파일은 삭제된 것으로 표시된 행을 고려한 후 50% 미만의 전체로 표시됩니다. 병합 작업은 이러한 두 CFP를 결합하고 이러한 두 CFP의 결합 범위인 200보다 크고 400보다 작거나 같은 타임스탬프가 있는 트랜잭션을 포함하는 새 CFP를 만듭니다. 트랜잭션 범위에 대한 범위(500, 600] 및 비어있지 않은 델타 파일(200, 400)가 있는 다른 CFP는 원본 CFP에서 더 많은 행을 삭제하는 것을 포함하여 트랜잭션 작업과 동시에 병합 작업을 수행할 수 있음을 보여 줍니다.
백그라운드 스레드는 병합 정책을 사용하여 닫힌 모든 CFP를 평가한 다음 한정된 CFP에 대해 하나 이상의 병합 요청을 시작합니다. 이러한 병합 요청은 오프라인 검사점 스레드에서 처리됩니다. 병합 정책의 평가는 정기적으로 수행되며 검사점이 닫힌 경우에도 수행됩니다.
SQL Server 2014(12.x) 병합 정책
SQL Server 2014(12.x)는 다음 병합 정책을 구현합니다.
삭제된 행을 고려한 후 2개 이상의 연속 CFP를 통합할 수 있으면 병합이 예약되므로 결과 행이 이상적인 크기의 CFP 1개에 맞을 수 있습니다. CFP의 이상적인 크기는 다음과 같이 결정됩니다.
컴퓨터에 16GB 미만의 메모리가 있는 경우 데이터 파일은 16MB이고 델타 파일은 1MB입니다.
컴퓨터에 16GB 이상의 메모리가 있는 경우 데이터 파일은 128MB이고 델타 파일은 16MB입니다.
데이터 파일이 256MB를 초과하고 행의 절반 이상이 삭제되는 경우 단일 CFP를 자체 병합할 수 있습니다. 예를 들어 단일 트랜잭션 또는 여러 동시 트랜잭션이 대량의 데이터를 삽입하거나 업데이트하는 경우 트랜잭션이 여러 CFP에 걸쳐서는 안 되므로 데이터 파일이 이상적인 크기 이상으로 커지도록 하는 경우 데이터 파일은 128MB보다 커질 수 있습니다.
다음은 병합 정책에 따라 병합될 CFP를 보여 주는 몇 가지 예입니다.
| 인접한 CFP 원본 파일들 (% 전체) | 선택 영역 합치기 |
|---|---|
| CFP0 (30%), CFP1 (50%), CFP2 (50%), CFP3 (90%) | (CFP0, CFP1) CFP2는 결과 데이터 파일이 이상적인 크기의 100%를 초과하게 되므로 선택되지 않습니다. |
| CFP0 (30%), CFP1 (20%), CFP2 (50%), CFP3 (10%) | (CFP0, CFP1, CFP2). 파일은 왼쪽부터 선택됩니다. CTP3은 결과 데이터 파일을 이상적인 크기의 100% 초과할 수 있으므로 선택되지 않습니다. |
| CFP0 (80%), CFP1 (30%), CFP2 (10%), CFP3 (40%) | (CFP1, CFP2, CFP3). 파일은 왼쪽부터 선택됩니다. CFP0은 CFP1과 결합된 경우 결과 데이터 파일이 이상적인 크기의 100%보다 커지므로 생략됩니다. |
사용 가능한 공간이 있는 모든 CFP가 병합할 자격이 있는 것은 아닙니다. 예를 들어 인접한 두 CFP가 60개% 가득 차면 병합할 자격이 없으며 이러한 각 CFP에는 40개의% 스토리지가 사용되지 않습니다. 최악의 경우 모든 CFP가 50%까지 차게 될 것이며, 스토리지 사용률은 50%에 불과합니다. 삭제된 행은 CFP가 병합 요건을 충족하지 않기 때문에 스토리지에 남아 있을 수 있지만, 메모리 내 가비지 수집으로 인해 이미 메모리에서 제거되었을 가능성도 있습니다. 스토리지 및 메모리 관리는 가비지 수집과 독립적입니다. 활성 CFP에서 사용하는 스토리지(모든 CFP가 업데이트되는 것은 아님)는 메모리의 지속성 테이블 크기보다 최대 2배 더 클 수 있습니다.
필요한 경우 sys.sp_xtp_merge_checkpoint_files(Transact-SQL)를 호출하여 수동 병합을 명시적으로 수행할 수 있습니다.
CFP의 수명 주기
CPF는 할당 취소 전에 여러 상태를 거칩니다. 언제든지 CFP는 다음 중 하나의 단계에 있습니다: 생성 전 (PRECREATED), 건설 중 (UNDER CONSTRUCTION), 활성 (ACTIVE), 병합 대상 (MERGE TARGET), 병합 원본 (MERGED SOURCE), 백업/고가용성을 위해 필요 (REQUIRED FOR BACKUP/HA), 무효화로 전환 중 (IN TRANSITION TO TOMBSTONE), 그리고 무효화 (TOMBSTONE). 이러한 단계에 대한 설명은 sys.dm_db_xtp_checkpoint_files(Transact-SQL)를 참조하세요.
다양한 상태에서 CFP가 사용하는 스토리지를 고려한 후 지속성 메모리 최적화 테이블에서 사용하는 전체 스토리지는 메모리에 있는 테이블 크기의 2배보다 훨씬 클 수 있습니다. DMV sys.dm_db_xtp_checkpoint_files(Transact-SQL) 를 쿼리하여 해당 단계를 포함하여 메모리 최적화 파일 그룹의 모든 CFP를 나열할 수 있습니다. 데이터베이스가 전체 복구 모델 또는 대량 로그 복구 모델에 맞게 구성된 경우, CFP를 MERGE SOURCE 상태에서 TOMBSTONE으로 전환한 후 궁극적으로 가비지 수집까지 진행하는 데에는 최대 5개의 체크포인트가 필요할 수 있으며, 각 체크포인트 후에는 트랜잭션 로그 백업이 수행됩니다.
검사점과 로그 백업을 강제로 강제 적용하여 가비지 수집을 신속하게 수행할 수 있지만, 그러면 5개의 빈 CFP(각각 크기가 128MB인 데이터 파일 5개/델타 파일 쌍)가 추가됩니다. 프로덕션 시나리오에서 백업 전략의 일부로 수행되는 자동 검사점 및 로그 백업은 수동 개입 없이 이러한 단계를 통해 CFP를 원활하게 전환합니다. 가비지 수집 프로세스의 영향은 메모리 최적화 테이블이 있는 데이터베이스의 스토리지 크기가 메모리 크기에 비해 클 수 있다는 것입니다. CFP가 메모리 내의 내구성 메모리 최적화 테이블 크기보다 최대 4배까지 큰 것은 드문 일이 아닙니다.