메모리 액세스에 최적화된 테이블의 복원 및 복구Restore and Recovery of Memory-Optimized Tables

이 항목 적용 대상: 예SQL Server없습니다Azure SQL 데이터베이스없습니다Azure SQL 데이터 웨어하우스 없습니다 병렬 데이터 웨어하우스THIS TOPIC APPLIES TO: yesSQL ServernoAzure SQL DatabasenoAzure SQL Data Warehouse noParallel Data Warehouse

메모리 최적화 테이블이 있는 데이터베이스를 복구하거나 복원하기 위한 기본 메커니즘은 디스크 기반 테이블만 있는 데이터베이스와 비슷합니다.The basic mechanism to recover or restore a database with memory-optimized tables is similar to databases with only disk-based tables. 하지만 디스크 기반 테이블과 달리, 메모리 최적화 테이블은 먼저 메모리에 로드해야만 사용자가 데이터베이스에 액세스할 수 있습니다.But unlike disk-based tables, memory-optimized tables must be loaded into memory before database is available for user access. 따라서 데이터베이스 복구에 새로운 단계가 추가됩니다.This adds a new step in the database recovery.

복구 또는 복원 작업 중에 메모리 내 OLTP 엔진은 물리적 메모리에 로드하기 위해 데이터 및 델타 파일을 읽습니다.During recovery or restore operations, the In-Memory OLTP engine reads data and delta files for loading into physical memory. 로드 시간을 결정하는 요소는 다음과 같습니다.The load time is determined by:

  • 로드할 데이터의 양The amount of data to load.

  • 순차 I/O 대역폭Sequential I/O bandwidth.

  • 파일 컨테이너 및 프로세서 코어의 수로 결정되는 병렬 처리 수준Degree of parallelism, determined by number of file containers and processor cores.

  • 다시 실행해야 할 로그의 활성 부분에 있는 로그 레코드의 양입니다.The amount of log records in the active portion of the log that need to be redone.

    SQL ServerSQL Server 가 다시 시작되면 각 데이터베이스가 다음 세 단계로 구성된 복구 단계를 거칩니다.When the SQL ServerSQL Server restarts, each database goes through a recovery phase that consists of the following three phases:

  1. 분석 단계.The analysis phase. 이 단계 중에는 커밋된 트랜잭션과 커밋되지 않은 트랜잭션을 감지하기 위한 패스가 활성 트랜잭션 로그에 작성됩니다.During this phase, a pass is made on the active transaction logs to detect committed and uncommitted transactions. 메모리 내 OLTP 엔진은 로드할 검사점을 식별하고 시스템 테이블 로그 항목을 미리 로드합니다.The In-Memory OLTP engine identifies the checkpoint to load and preloads its system table log entries. 또한 일부 파일 할당 로그 레코드도 처리합니다.It will also process some file allocation log records.

  2. 다시 실행 단계.The redo phase. 이 단계는 디스크 기반 테이블과 메모리 최적화 테이블에서 동시에 실행됩니다.This phase is run concurrently on both disk-based and memory-optimized tables.

    디스크 기반 테이블의 경우 데이터베이스가 현재 시점으로 이동하고 커밋되지 않은 트랜잭션에 있는 잠금을 획득합니다.For disk-based tables, the database is moved to the current point in time and acquires locks taken by uncommitted transactions.

    메모리 최적화 테이블의 경우 데이터 및 델타 파일 쌍의 데이터가 메모리에 로드된 다음 마지막 지속성 검사점을 기반으로 활성 트랜잭션 로그를 사용하여 데이터를 업데이트합니다.For memory-optimized tables, data from the data and delta file pairs are loaded into memory and then update the data with the active transaction log based on the last durable checkpoint.

    디스크 기반 테이블과 메모리 최적화 테이블에서 위의 연산이 완료되면 데이터베이스에 액세스할 수 있습니다.When the above operations on disk-based and memory-optimized tables are complete, the database is available for access.

  3. 실행 취소 단계.The undo phase. 이 단계에서는 커밋되지 않은 트랜잭션이 롤백됩니다.In this phase, the uncommitted transactions are rolled back.

    메모리 최적화 테이블을 메모리에 로드하면 RTO(복구 시간 목표)의 성능에 영향을 줄 수 있습니다.Loading memory-optimized tables into memory can affect performance of the recovery time objective (RTO). 데이터 및 델타 파일에서 메모리 최적화 데이터를 로드하는 시간을 개선하기 위해 메모리 내 OLTP 엔진은 다음과 같이 데이터/델타 파일을 병렬로 로드합니다.To improve the load time of memory-optimized data from data and delta files, the In-Memory OLTP engine loads the data/delta files in parallel as follows:

  • 델타 맵 필터 만들기.Creating a Delta Map Filter. 델타 파일은 삭제된 행에 대한 참조를 저장합니다.Delta files store references to the deleted rows. 컨테이너당 하나의 스레드가 델타 파일을 읽고 델타 맵 필터를 만듭니다.One thread per container reads the delta files and creates a delta map filter. 메모리 액세스에 최적화된 데이터 파일 그룹에는 하나 이상의 컨테이너가 있을 수 있습니다.(A memory optimized data filegroup can have one or more containers.)

  • 데이터 파일 스트리밍.Streaming the data files. 델타 맵 필터가 생성되면 논리적 CPU와 같은 수의 스레드를 사용하여 데이터 파일을 읽습니다.Once the delta-map filter is created, data files are read using as many threads as there are logical CPUs. 데이터 파일을 읽는 각 스레드는 데이터 행을 읽고 연결된 델타 맵을 확인한 다음 이 행이 삭제됨으로 표시되지 않은 경우에만 테이블에 행을 삽입합니다.Each thread reading the data file reads the data rows, checks the associated delta map and only inserts the row into table if this row has not been marked deleted. 복구의 이 부분은 아래 설명과 같이 일부 경우에 CPU 바인딩될 수 있습니다.This part of recovery can be CPU bound in some cases as noted below.

    메모리 액세스에 최적화된 테이블Memory-optimized tables.

    메모리 액세스에 최적화된 테이블은 일반적으로 I/O 속도로 메모리에 로드할 수 있지만 데이터 행을 메모리에 로드하는 것이 더 느린 경우가 있습니다.Memory-optimized tables can generally be loaded into memory at the speed of I/O but there are cases when loading data rows into memory will be slower. 구체적인 경우는 다음과 같습니다.Specific cases are:

  • 해시 인덱스의 버킷 수가 적으면 과도한 충돌이 발생하여 데이터 행 삽입이 느려질 수 있습니다.Low bucket count for hash index can lead to excessive collision causing data row inserts to be slower. 이 경우 일반적으로 전체 CPU 사용률이 매우 높아지며 복구가 거의 끝날 때 특히 높아집니다.This generally results in very high CPU utilization throughout, and especially towards the end of recovery. 해시 인덱스를 올바르게 구성한 경우 복구 시간에 영향을 미치지 않습니다.If you configured the hash index correctly, it should not impact the recovery time.

  • 하나 이상의 비클러스터형 인덱스가 있는 대규모 메모리 최적화 테이블의 경우 생성 시간에 버킷 수가 조정되는 해시 인덱스와는 달리 비클러스터형 인덱스가 동적으로 증가하여 결과적으로 CPU 사용률이 높아집니다.Large memory-optimized tables with one or more nonclustered indexes, unlike a hash index whose bucket count is sized at create time, the nonclustered indexes grow dynamically, resulting in high CPU utilization.

참고 항목See Also

메모리 액세스에 최적화된 테이블의 백업, 복원 및 복구Backup, Restore, and Recovery of Memory-Optimized Tables