Accelerated database recovery 즉 ADR은 SQL Server 2019부터 새로 적용된 기능이다.
해당 기능은 오래 실행되는 Transaction이 있을 시에 빠르게 복구 프로세스를 진행할 수 있도록 해준다.
ADR의 장점은 다음과 같다.
l 빠르고 일관된 데이터베이스 복구
- 오래 실행된 Transaction 복구 시간에 영향을 주지 않으므로 진행된 Transaction의 크기에 상관없이 빠르게 복구된다.
l 즉시 Transaction Rollback
- Transaction이 실행된 시간 또는 Update된 수에 상관없이 즉시 rollback 된다.
l 향상된 Log 분할
- Transaction의 Log 더욱 자잘하게 잘려 제어할 수 없는 상태를 예방한다.
기존의 데이터베이스 복구 프로세스
ADR을 사용하지 않을 경우 ARIES 복구 모델을 따라 위 그림과 같이 3개의 파트로 구성되어 복구된다.
1. 분석 단계
SQL Server (또는 Query)가 중지되었을 때 SQL Server 가 마지막으로 저장한 CheckPoint의 시작부분에서 정방향으로 조회해서 Transaction Log의 끝까지 검사하여 각 Transaction의 상태를 분석한다.
2. 다시 실행 단계
SQL Server (또는 Query)가 중지될 때까지 Commit되지 않은 가장 오래된 Transaction의 처음부터 Transaction Log의 마지막 까지 Commit을 진행한다.
3. 실행 취소 단계
SQL Server (또는 Query)가 중지될 때 활성화 되어 있는 모든 Transaction에 대해 로그를 역방향 조회하여 Commit 내용을 모두 취소한다.
결국 장애 발생 시나 쿼리 취소 시 불완전 실행된 모든 Transaction은 Rollback 해야 하는데 이 때 수행되는 시간은 가장 오래 진행된 Transaction의 크기에 비례 하기 때문에 오래 걸리는 작업이 있었을 시 복구가 오래 걸리게 되는 것이다.[ex) 큰테이블의 변경, 인덱스 재구성 등]
또한 복구를 위해 오래 진행된 Transaction의 Log를 저장하게 됨으로 디스크 드라이브를 많이 사용하데 된다.
가속 데이터베이스 복구 프로세스
가장 오래 진행된 Transaction의 시박 부분에서 로그를 검색하지 않도록 하기 위해 시간/인스턴트를 일정하게 만듭니다. 따라서 ADR을 사용 시 복구는 마지막 성공 CheckPoint 부터 Transaction Log 마지막까지만 처리된다
전체 Transaction Log를 처리할 필요가 없기 때문에 Transaction Log 공간을 최소화 할 수 있다.
1. 분석 단계
SQL Server (또는 Query)가 중지되었을 때 SQL Server 가 마지막으로 저장한 CheckPoint의 시작부분에서 정방향으로 조회해서 Transaction Log의 끝까지 검사하여 각 Transaction의 상태를 분석한다.
또한 sLog를 재 작성하고 Log 행을 복사한다.
2. 다시 실행 단계
A. 하위 1단계 : sLog에서 마지막 저장 CheckPoint까지 다시 실행 한다. sLog에서 몇개의 행만 처리하면 되기 때문에 빠르다.
B. 하위 2단계 : 마지막 저장 CheckPoint에서 Transaction Log의 마지막 까지 Commit을 진행한다.
3. 실행 취소 단계
sLog를 활욜하여 작업 실행을 취소하고 PVS(persisted version store)를 실행하여 Row Versioning를 실행 취소를 수행하여 거의 즉시 완료된다.
가속 데이터베이스 복구의 구성 요소는 다음과 같다.
l PVS(지속형 버전 저장소)
- 기존의 Version Store와 다르게 tempdb가 아닌 해당 데이터베이스 자체에 Version Store를 유지한다.
- 리소스 격리를 사용할 수 있도록 하고 읽기 가능한 복제본의 가용성을 개선한다.(Always On 지원)
l Logical Revert
- 즉시 Transaction Rollback 및 실행 취소를 위해 제공하는 Version Store 기반의 실행취소를 수행하는 비동기 프로세스
- 중단된 모든 Transaction을 추적
- 모든 User Transaction에 대한 PVS를 이용한 Rollback 수행
- Transaction 이 중단된 직후 모든 Lock 해제
l sLog
- 버전이 없는 작업(Meta Cache 무효화, Lock 획득) 에 대한 로그 행을 저장하는 보조 메모리 내 Log Stream
- 적은 볼륨 또는 매모리 내에 존재
- CheckPoint와 함께 디스크에 유지
- Transaction이 Commit 될 때 자동 분할 발생
- Version이 없는 작업만 처리 해서 다시 실행 및 실행 취소를 가속화 함
- 필요한 로그 행만 유지하여 Transaction Log를 자주 분할함
l 클리너
- 정기적으로 필요 없는 page version 을 정리
ADR 설정 방법
먼저 테스트 데이터베이스에 파일 그룹 및 파일을 추가 해주었다.
해당 데이터베이스의 Version Store는 해당 파일에 저장된 것이다.
그리고 데이터베이스에 ADR 옵션을 활성화 한다.
(활성화 이전에 먼저 ALTER DATABASE 구문이 진행될 것이므로 모든 연결을 해제 시켜야 한다.)
ALTER DATABASE AdventureWorks2019 SET SINGLE_USER WITH ROLLBACK IMMEDIATE
ALTER DATABASE AdventureWorks2019
SET ACCELERATED_DATABASE_RECOVERY = ON
(PERSISTENT_VERSION_STORE_FILEGROUP = PVS)
ALTER DATABASE AdventureWorks2019 SET MULTI_USER
PVS 파일 그룹 변경 방법은 다음과 같이 진행한다.
먼저 ADR을 종료한다.
그 후 sys.sp_persistent_version_cleanup 을 이용하여 해당 파일에 저장되어 있던 PVS를 제거하고 제거된 여부를 확인하다.
그 후 파일 그룹을 변경하여 ADR를 활성화 한다.
ALTER DATABASE AdventureWorks2019
SET ACCELERATED_DATABASE_RECOVERY = OFF
EXEC sys.sp_persistent_version_cleanup 'AdventureWorks2019'
SELECT B.name
, A.database_id
, A.persistent_version_store_size_kb
FROM sys.dm_tran_persistent_version_store_stats AS A
INNER JOIN sys.databases AS B
ON A.database_id = B.database_id
WHERE B.name = 'AdventureWorks2019'
ALTER DATABASE AdventureWorks2019
SET ACCELERATED_DATABASE_RECOVERY = ON
(PERSISTENT_VERSION_STORE_FILEGROUP = PRIMARY)
ADR의 문제점
tempdb가 아닌 각 데이터베이스에 PVS를 생성하고 Transaction 진행 중 Commit된 상황에 대해 sLog를 생성하는 작업을 진행하기 때문에 다음과 같은 항목에 오버헤드가 발생된다.
Transaction 이 발생되었을 때 Buffer cache에서 작업이 영향 받는 Page를 올리고 해당 Page의 값을 수정하게 되면 Dirty Page가 되고 해당 Dirty page를 Disk에 저장하는 방식이다.
l background write page/sec
- 복구 간격 설정을 위해 Flush된 초당 Page 수
- sLog 생성을 위해 발생된다.
l page writes/sec
- Buffer cache에 있은 Dirty Page를 물리적 Disk에 쓰기 한 초당 Page 수
- Version Store가 tempdb가 아닌 각 Databases에 생성이 되어 있고 해당 Version Store에 Row Versioning 하면서 발생된 쓰기 작업도 포함되어 해당 수치가 올라가는 것으로 예상한다.
l context switch/sec
- SQL Server가 작업 Thread가 다른 Thread로 초당 전환되는 횟수
- sLog에 의해 Transaction Log 분할이 이루어 질 때마다 Thread가 전환되어 해당 값이 올라가는 것 같다.
ADR을 고려해야 하는 경우
다음과 같은 Service를 진행 중이라면 ADR을 고려해야 한다.
대용량 테이블의 DDL 작업을 통해 Transaction Log가 크게 증가하고 쿼리의 실행이 오랜 시간 작업되는 경우가 있는 서비스
쿼리 실행 시 장기간으로 실행되는 경우가 많은 DW 관련 서비스를 운영하고 있는 경우가 적합해 보인다.
추가적으로 SQL Server 장기 실행 복구로 인해 데이터베이스를 장기간 사용하지 못한 경험이 있다면 고려해보아도 좋다.
참조
'Database > SQL Server' 카테고리의 다른 글
| 가속 데이터베이스 복구 [ADR] (2) Version Store 운영 및 모니터링 (0) | 2021.11.23 |
|---|---|
| 가속 데이터베이스 복구 [ADR] (1) Row Versioning (0) | 2021.11.18 |
| SQL Server Connection Pool 대하여 (0) | 2021.11.11 |
| 가용성 그룹(Always On) 구축 [On Azure] (7) 수신기 구성 (0) | 2021.10.01 |
| 가용성 그룹(Always On) 구축 [On Azure] (6) Alaways On 구성 (0) | 2021.09.29 |
최근댓글