다음을 통해 공유

가속 데이터베이스 복구

  • 아티클

적용 대상:Microsoft Fabric의 SQL Server 2019(15.x) 이상 버전 Azure SQL Database Azure SQL Managed InstanceSQL 데이터베이스

ADR(가속 데이터베이스 복구)은 데이터베이스 엔진 복구 프로세스를 다시 설계하여 특히 장기 실행 트랜잭션이 있는 경우 데이터베이스 가용성을 향상시킵니다.

ADR은 SQL Server 2019(15.x)의 새로운 기능이며 SQL Server 2022(16.x)에서 개선되었습니다. ADR은 Azure SQL Database, Azure SQL Managed Instance, Azure Synapse Analytics(전용 SQL 풀만 해당) 및 Microsoft Fabric의 SQL 데이터베이스에서도 사용할 수 있습니다.

메모

ADR은 항상 Azure SQL Database, Azure SQL Managed Instance 및 Fabric의 SQL 데이터베이스에서 사용하도록 설정됩니다.

이 문서에서는 ADR에 대한 개요를 제공합니다. ADR을 사용하려면 가속화된 데이터베이스 복구 관리를 검토합니다.

트랜잭션 로그 및 데이터베이스 복구에 대한 자세한 내용은 SQL Server 트랜잭션 로그 아키텍처 및 관리 가이드 및 복원 및 복구 개요(SQL Server)참조하세요.

개요

ADR의 주요 이점은 다음과 같습니다.

  • 빠르고 일관된 데이터베이스 복구

    장기 실행 트랜잭션은 전체 복구 시간에 영향을 주지 않으므로 시스템의 활성 트랜잭션 수 또는 크기에 관계없이 빠르고 일관된 데이터베이스 복구를 사용할 수 있습니다.

  • 즉각적인 트랜잭션 롤백

    트랜잭션 롤백은 트랜잭션이 활성화된 시간 또는 수행된 업데이트 수에 관계없이 즉시 수행됩니다.

  • 적극적인 로그 자르기

    트랜잭션 로그는 활성 장기 실행 트랜잭션이 있는 경우에도 공격적으로 잘려서 로그가 통제 불능으로 커지는 것을 방지합니다.

기존 데이터베이스 복구 프로세스

ADR이 없으면 데이터베이스 복구는 ARIES 복구 모델을 따르며 다음 도표에서 자세히 설명하는 세 단계로 구성됩니다.

현재 복구 프로세스의 다이어그램입니다.

  • 분석 단계

    데이터베이스 엔진은 마지막으로 성공한 검사점(또는 가장 오래된 LSN(페이지 로그 시퀀스 번호))의 시작부터 끝까지 트랜잭션 로그의 정방향 검사를 수행하여 엔진이 중지될 때 각 트랜잭션의 상태를 확인합니다.

  • 다시 실행 단계

    데이터베이스 엔진은 커밋되지 않은 가장 오래된 트랜잭션에서 끝까지 트랜잭션 로그의 전방 검사를 수행합니다. 이 프로세스는 커밋된 모든 작업을 다시 실행하여 충돌 시 데이터베이스를 해당 상태로 복원합니다.

  • 실행 취소 단계

    크래시 당시 활성 상태였던 각 트랜잭션에 대해 데이터베이스 엔진은 로그를 뒤로 트래버스하여 이 트랜잭션이 수행한 작업을 실행 취소합니다.

  • 기존 데이터베이스 복구 프로세스를 사용하면 장기 실행 트랜잭션이 활성화된 경우 크래시 후 복구에 오랜 시간이 걸릴 수 있습니다.

    데이터베이스 엔진이 예기치 않은 재시작에서 복구에 걸리는 시간은 시스템 장애 당시 시스템에서 가장 긴 활성 트랜잭션의 크기와 대략적으로 비례 관계가 있습니다. 복구하려면 불완전한 모든 트랜잭션을 롤백해야 합니다. 필요한 시간은 트랜잭션이 수행한 작업과 트랜잭션이 활성화된 시간에 비례합니다.

  • 이전에 설명한 것과 동일한 실행 취소 복구 단계를 사용하므로 큰 트랜잭션을 취소하거나 롤백하는 데 시간이 오래 걸릴 수 있습니다.

  • 복구 및 롤백 프로세스에 해당 로그 레코드가 필요하기 때문에 장기 실행 트랜잭션이 있는 경우 데이터베이스 엔진에서 트랜잭션 로그를 잘라낼 수 없습니다. 결과적으로 트랜잭션 로그는 매우 커지고 많은 스토리지 공간을 사용할 수 있습니다.

가속화된 데이터베이스 복구 프로세스

ADR은 데이터베이스 엔진 복구 프로세스를 다음과 같이 완전히 다시 디자인하여 기존 복구 모델의 이전 문제를 해결합니다.

  • 더 이상 가장 오래된 활성 트랜잭션의 시작 부분에서 트랜잭션 로그를 검색할 필요가 없으므로 복구 시간을 일정하게 만듭니다. ADR을 사용하면 트랜잭션 로그는 마지막으로 성공한 검사점(또는 가장 오래된 더티 페이지 LSN)에서만 처리됩니다. 따라서 복구 시간은 장기 실행 트랜잭션의 영향을 받지 않으며 일반적으로 즉시 발생합니다.

  • 전체 트랜잭션에 대한 로그를 더 이상 유지할 필요가 없으므로 필요한 트랜잭션 로그 공간을 최소화합니다. 따라서 검사점 및 백업이 수행되면 트랜잭션 로그를 적극적으로 잘라낼 수 있습니다.

높은 수준에서 ADR은 모든 물리적 데이터베이스 수정 사항의 버전 관리 및 비버전되지 않은 작업만 실행 취소하여 빠른 데이터베이스 복구를 달성합니다. 이 작업은 제한되며 거의 즉시 실행 취소할 수 있습니다. 작업 중지 당시 활성 상태였던 모든 트랜잭션은 중단된 것으로 표시되므로 이러한 트랜잭션에서 생성된 모든 버전은 동시 사용자 쿼리에서 무시될 수 있습니다.

ADR 복구 프로세스에는 기존 복구 프로세스와 동일한 세 단계가 있습니다. 이러한 단계가 ADR로 작동하는 방식은 다음 다이어그램에 나와 있습니다.

ADR 복구 프로세스의 다이어그램입니다.

  • 분석 단계

    이 프로세스는 SLOG(보조 로그 스트림)를 다시 구성하고 변환되지 않은 작업에 대한 로그 레코드를 복사하는 기능을 추가하여 기존 복구 모델과 동일하게 유지됩니다.

  • 다시 실행 단계

    두 하위 단계로 나뉩니다.

    • 하위 단계 1

      SLOG를 기준으로, 커밋되지 않은 가장 오래된 트랜잭션부터 마지막 검사점까지 다시 시작합니다. 다시 실행은 SLOG에서 몇 가지 레코드만 처리하면 되므로 빠른 작업입니다.

    • 하위 단계 2

      트랜잭션 로그에서의 재실행은 커밋되지 않은 가장 오래된 트랜잭션 대신 마지막으로 성공한 검사점에서 시작됩니다.

  • 실행 취소 단계

    ADR을 사용한 실행 취소 단계는 SLOG로 비버전 작업을 실행 취소하고, 논리 되돌리기를 통해 영구 버전 저장소(PVS)를 사용하여 행 수준의 버전 기반 실행 취소를 수행함으로써 거의 즉시 완료됩니다.

가속화된 데이터베이스 복구에 대한 설명은 이 8분 분량의 비디오를 시청하세요.

ADR 복구 구성 요소

ADR의 네 가지 구성 요소는 다음과 같습니다.

  • PVS(영구 버전 저장소)

    PVS(영구 버전 저장소)는 tempdb 데이터베이스의 기존 버전 저장소 대신 데이터베이스 자체에서 행 버전을 유지하기 위한 데이터베이스 엔진 메커니즘입니다. PVS는 리소스 격리를 가능하게 하고 읽을 수 있는 보조 복제본의 가용성을 향상시킵니다.

  • 논리 되돌리기

    논리적 되돌리기는 모든 버전의 작업에 대해 즉시 트랜잭션 롤백 및 실행 취소를 제공하는 행 수준 버전 기반 실행 취소를 수행하는 비동기 프로세스입니다.

    • 중단된 모든 트랜잭션을 추적합니다.
    • 모든 사용자 트랜잭션에 대해 PVS를 사용하여 롤백 수행
    • 트랜잭션이 중단된 직후 모든 잠금 해제

  • SLOG

    SLOG는 버전이 없는 작업(예: 메타데이터 캐시 무효화, 잠금 획득 등)에 대한 로그 레코드를 저장하는 보조 메모리 내 로그 스트림입니다. SLOG 다음과 같습니다.

    • 낮은 볼륨 및 인메모리(in-memory)
    • 검사점 프로세스 중 디스크에 유지됨
    • 트랜잭션 커밋으로 주기적으로 잘립니다.
    • 변환되지 않은 작업만 처리하여 다시 실행 및 실행 취소를 가속화합니다.
    • 필요한 로그 레코드만 유지하여 적극적인 트랜잭션 로그 잘림을 사용하도록 설정합니다.

  • 클리너

    클리너는 정기적으로 절전 모드를 해제하고 필요하지 않은 행 버전을 정리하는 비동기 프로세스입니다.

ADR의 이점을 활용하는 워크로드

ADR은 다음이 있는 워크로드에 특히 유용합니다.

  • 장기적으로 실행되는 트랜잭션.
  • 트랜잭션 로그가 크게 증가하는 활성 트랜잭션입니다.
  • 장기 실행 복구(예: 예기치 않은 서비스 다시 시작 또는 수동 트랜잭션 롤백)로 인해 장기간 데이터베이스를 사용할 수 없습니다.

ADR 모범 사례

  • 불필요한 오래 지속되는 트랜잭션을 피합니다. ADR은 장기 실행 트랜잭션에서도 데이터베이스 복구 속도를 높이지만 이러한 트랜잭션은 버전 정리를 지연시키고 PVS의 크기를 늘릴 수 있습니다.

  • DDL 작업을 포함하는 큰 트랜잭션을 방지합니다. ADR은 SLOG(보조 로그 스트림) 메커니즘을 사용하여 복구에 사용되는 DDL 작업을 추적합니다. SLOG는 트랜잭션이 활성화된 동안에만 사용됩니다. SLOG는 검사점 처리가 되어 있으므로, 따라서 SLOG를 사용하는 대규모 트랜잭션을 피하면 전반적인 성능 향상에 도움이 될 수 있습니다. 이러한 시나리오로 인해 SLOG가 더 많은 공간을 차지할 수 있습니다.

    • 많은 DDL이 하나의 트랜잭션에서 실행됩니다. 예를 들어 한 트랜잭션에서 임시 테이블을 빠르게 만들고 삭제합니다.
    • 테이블에는 매우 많은 수의 파티션/인덱스가 수정됩니다. 예를 들어, 이러한 테이블에서 DROP TABLE 작업을 수행하려면 SLOG 메모리를 대량으로 예약해야 하며, 이는 트랜잭션 로그의 잘림을 지연시키고 실행 취소/다시 실행 작업을 지연시킬 수 있습니다. 해결 방법으로 인덱스를 개별적으로 점진적으로 삭제한 다음 테이블을 삭제합니다.

    SLOG에 대한 자세한 내용은 ADR 복구 구성 요소를 참조하세요.

  • 불필요한 중단된 트랜잭션을 방지하거나 줄입니다. 트랜잭션 중단률이 높을수록 PVS 클리너에 대한 압박이 가중되고 ADR 성능이 저하됩니다. 중단은 높은 교착 상태, 중복 키, 제약 조건 위반 또는 쿼리 시간 제한에서 비롯될 수 있습니다. sys.dm_tran_aborted_transactions DMV는 데이터베이스 엔진 인스턴스에서 모든 중단된 트랜잭션을 보여줍니다. nested_abort 열은 트랜잭션이 커밋되었지만 중단된 부분(저장점 또는 중첩된 트랜잭션)이 있음을 나타내고 PVS 정리 프로세스를 지연시킬 수도 있습니다.

  • 데이터베이스에 PVS 사용을 고려할 충분한 공간이 있는지 확인합니다. 데이터베이스에 PVS를 확장할 충분한 공간이 없으면 ADR이 버전을 생성하지 못해 DML 문이 실패할 수 있습니다.

  • 쓰기 집약적 워크로드에서 ADR을 사용하도록 설정하면 PVS에 기록된 행 버전이 기록되므로 트랜잭션 로그 생성 속도가 크게 증가할 수 있습니다. 이렇게 하면 트랜잭션 로그 백업의 크기가 증가할 수 있습니다.

  • 트랜잭션 복제, 스냅샷 복제, 또는 CDC(변경 데이터 캡처)를 사용할 경우, ADR의 적극적인 로그 잘림 동작이 비활성화되어 로그 판독기가 트랜잭션 로그에서 변경 내용을 수집할 수 있습니다. 트랜잭션 로그가 충분히 큰지 확인합니다.

    Azure SQL Database에서는 모든 워크로드의 요구에 충분한 트랜잭션 로그 공간을 사용할 수 있도록 서비스 계층 또는 컴퓨팅 크기를 늘려야 할 수 있습니다. 마찬가지로 Azure SQL Managed Instance에서 인스턴스 최대 스토리지 크기를 늘려야 할 수도 있습니다.

  • SQL Server의 경우, 고급 SSD나 최신 SSD 또는 영구 메모리(PMEM)와 같은 상위 계층 스토리지에 있는 파일 그룹으로 PVS 버전 저장소를 격리해야 합니다. 이러한 스토리지는 때로는 SCM(스토리지 클래스 메모리)이라고도 합니다. 자세한 내용은 을(를) 참조하여 PVS의 위치를 다른 파일 그룹으로 변경하십시오.

  • SQL Server의 경우 PreallocatePVS 항목에 대한 오류 로그를 모니터링합니다. PreallocatePVS 항목이 있는 경우 백그라운드 작업을 사용하여 페이지를 미리 할당하는 ADR 기능을 늘려야 할 수 있습니다. 백그라운드에서 PVS 페이지를 미리 할당하면 더 비싼 포그라운드 PVS 할당을 줄여 ADR 성능이 향상됩니다. ADR Preallocation Factor 서버 구성을 사용하여 이 크기를 늘릴 수 있습니다. 자세한 내용은 서버 구성을 참조하세요. ADR 사전 할당 요소.

  • SQL Server 2022(16.x) 이상의 경우 단일 스레드 클리너 성능이 부족한 경우 다중 스레드 PVS 정리를 사용하도록 설정하는 것이 좋습니다. 자세한 내용은 서버 구성: ADR 클리너 스레드 수을 참조하세요.

  • PVS별 높은 데이터베이스 공간 사용량 또는 느린 PVS 정리와 같은 문제를 관찰하는 경우 가속 데이터베이스 복구문제 해결을 참조하세요.

SQL Server 2022의 ADR 개선 사항

PVS(영구 버전 저장소) 스토리지를 해결하고 전반적인 스케일링 성능을 개선하기 위해 몇 가지 개선 사항이 있습니다. SQL Server 2022(16.x)의 새로운 기능에 대한 자세한 내용은 SQL Server 2022새로운 기능을 참조하세요.

동일한 개선 사항은 Azure SQL Database, Azure SQL Managed Instance, Azure Synapse Analytics(전용 SQL 풀만 해당) 및 Microsoft Fabric의 SQL 데이터베이스에서도 사용할 수 있습니다.

  • 사용자 트랜잭션 정리

    잠금 획득 실패로 인해 일반 프로세스에서 정리할 수 없는 페이지를 정리합니다.

    이 기능을 사용하면 테이블 수준 잠금 충돌로 인해 일반 정리 프로세스에서 해결할 수 없는 페이지에서 사용자 트랜잭션이 정리를 실행할 수 있습니다. 이러한 개선 사항은 사용자 워크로드가 테이블 수준 잠금을 획득할 수 없기 때문에 ADR 정리 프로세스가 무기한 실패하지 않도록 하는 데 도움이 됩니다.

  • PVS 페이지 추적기 대한 메모리 공간 줄이기

    향상된 기능은 버전이 지정된 페이지를 유지하는 데 필요한 메모리 사용량을 줄이기 위해 익스텐트 레벨에서 PVS 페이지를 추적합니다.

  • PVS 클리너 개선

    PVS 클리너는 데이터베이스 엔진이 중단된 트랜잭션에 대한 행 버전을 추적하고 기록하는 방법을 개선하기 위해 버전 정리 효율성을 개선했습니다. 이로 인해 메모리 및 스토리지 사용량이 향상됩니다.

  • 트랜잭션 수준 영구 버전 저장소 (PVS)

    이 향상된 기능을 통해 ADR은 시스템에 중단된 트랜잭션이 있는지 여부에 관계없이 커밋된 트랜잭션에 속하는 버전을 정리할 수 있습니다. 개선된 기능 덕분에, 정리 작업이 중단된 트랜잭션 맵을 트리밍하는 데 성공적인 스윕을 완료하지 못하더라도 PVS 페이지를 해제할 수 있습니다.

    이 개선의 결과로, PVS 정리가 느리거나 실패하더라도 PVS의 성장이 줄어듭니다.

  • 다중 스레드 버전 정리

    SQL Server 2019(15.x)에서 정리 프로세스는 데이터베이스 엔진 인스턴스 내에서 단일 스레드됩니다.

    SQL Server 2022(16.x)부터 다중 스레드 버전 정리가 지원됩니다. 이렇게 하면 동일한 데이터베이스 엔진 인스턴스의 여러 데이터베이스를 병렬로 정리하거나 단일 데이터베이스를 더 빠르게 정리할 수 있습니다. 자세한 내용은 서버 구성의 ADR 클리너 스레드 수를 참조하세요.

    ADR PVS 다중 스레드 버전 클리너의 모니터링을 위해 tx_mtvc2_sweep_stats새로운 확장 이벤트가 추가되었습니다.

관련 콘텐츠