맨위로가기

ARIES

"오늘의AI위키"는 AI 기술로 일관성 있고 체계적인 최신 지식을 제공하는 혁신 플랫폼입니다.
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.

1. 개요

ARIES는 데이터베이스 복구를 위한 알고리즘으로, 로깅과 복구 과정을 통해 데이터베이스의 일관성을 유지한다. ARIES는 트랜잭션의 모든 연산을 시퀀스 번호와 함께 로그에 기록하며, 더티 페이지 테이블(DPT)과 트랜잭션 테이블(TT)을 사용하여 로그에 필요한 정보를 관리한다. 복구 과정은 분석, 재실행(Redo), 실행 취소(Undo) 단계로 이루어지며, 데이터베이스를 충돌 이전 상태로 복원한다. 또한, 검사점(Checkpoint)을 사용하여 복구 시간을 단축시키며, 퍼지 로깅 기법을 통해 데이터베이스 잠금 없이 검사점을 생성할 수 있다.

더 읽어볼만한 페이지

  • 데이터베이스 알고리즘 - 로그 선행 기입
    로그 선행 기입(WAL)은 데이터베이스 시스템에서 데이터 일관성, 충돌 안전성 및 안정성을 보장하는 기술로, 데이터 변경 사항을 디스크에 기록하기 전에 로그 파일에 먼저 기록하여 시스템 장애 시 데이터 손실을 최소화한다.
  • 데이터베이스 알고리즘 - 블록 중첩 루프
ARIES

2. 로깅 (Logging)

ARIES 알고리즘은 모든 데이터베이스 연산을 증가하는 시퀀스 번호와 함께 로깅한다. 일반적으로 결과 로그 파일은 충돌 및 하드웨어 고장으로부터 데이터를 보존할 수 있는 "안정적인 저장소"에 저장된다.

로그에 필요한 정보를 수집하기 위해 더티 페이지 테이블(DPT)과 트랜잭션 테이블(TT) 두 가지 자료 구조를 유지한다.

2. 1. 더티 페이지 테이블 (Dirty Page Table, DPT)

ARIES 알고리즘은 수정되었지만 아직 디스크에 기록되지 않은 페이지들의 목록과 해당 페이지를 더티 상태로 만든 첫 번째 로그 시퀀스 번호(LSN)를 기록한다.[1] 이를 위해 더티 페이지 테이블(DPT)이라는 자료 구조를 유지한다.[1]

2. 2. 트랜잭션 테이블 (Transaction Table, TT)

ARIES 알고리즘의 트랜잭션 테이블(TT)은 현재 실행 중인 모든 트랜잭션과 해당 트랜잭션이 생성한 마지막 로그 시퀀스 번호를 기록한다. 트랜잭션 테이블은 로그에 필요한 정보를 수집하기 위해 유지해야 하는 두 개의 자료 구조 중 하나이다.

모든 트랜잭션은 주어진 트랜잭션 ID에 대한 첫 번째 "업데이트" 유형 항목으로 암묵적으로 시작되며, 해당 트랜잭션에 대한 "로그 종료(End Of Log, EOL)" 항목으로 커밋된다.

2. 3. 로그 레코드 (Log Record)

ARIES 알고리즘은 모든 데이터베이스 연산을 증가하는 시퀀스 번호와 함께 로깅한다. 로그 레코드는 (시퀀스 번호, 트랜잭션 ID, 페이지 ID, Redo, Undo, 이전 시퀀스 번호) 형태로 생성된다. Redo 및 Undo 필드는 이 로그 레코드가 저장하는 변경 사항과 이를 실행 취소하는 방법에 대한 정보를 유지한다. 이전 시퀀스 번호는 이 트랜잭션에 대해 생성된 이전 로그 레코드를 참조한다. 중단된 트랜잭션의 경우, 이전 시퀀스 번호를 사용하여 로그 파일을 역순으로 탐색하여 특정 트랜잭션 내에서 수행된 모든 작업을 실행 취소할 수 있다.

복구 중이거나 중단된 트랜잭션의 작업을 실행 취소하는 동안, 해당 작업이 이미 실행 취소되었음을 기록하기 위해 특수한 종류의 로그 레코드인 보상 로그 레코드(CLR)가 기록된다. CLR은 (시퀀스 번호, 트랜잭션 ID, 페이지 ID, Redo, 이전 시퀀스 번호, 다음 실행 취소 시퀀스 번호) 형태이다. Redo 필드에는 되돌린 작업의 Undo 필드 적용 내용이 포함되어 있으며, CLR은 절대 되돌려지지 않으므로 Undo 필드는 생략된다.

2. 4. 보상 로그 레코드 (Compensation Log Record, CLR)

ARIES 알고리즘은 모든 데이터베이스 연산에 대해 증가하는 시퀀스 번호를 사용하여 로깅을 수행한다. 복구 과정이나 중단된 트랜잭션의 작업을 실행 취소하는 동안, 해당 작업이 이미 실행 취소되었음을 기록하기 위해 특수한 종류의 로그 레코드인 보상 로그 레코드(CLR)가 기록된다. CLR은 다음과 같은 형태를 가진다.[1]

항목설명
시퀀스 번호로그 레코드의 고유 식별 번호
트랜잭션 ID해당 작업을 수행한 트랜잭션의 식별 번호
페이지 ID변경된 페이지의 식별 번호
Redo되돌린 작업의 Undo 필드를 적용한 내용
이전 시퀀스 번호이 트랜잭션에 대해 생성된 이전 로그 레코드를 참조
다음 실행 취소 시퀀스 번호다음에 실행 취소할 로그 레코드의 시퀀스 번호



CLR에서 Redo 필드에는 되돌린 작업의 Undo 필드를 적용한 내용이 포함되며, CLR은 절대 되돌려지지 않으므로 Undo 필드는 생략된다.[1] CLR은 분석 단계에서 읽고 Redo 단계에서 다시 실행된다. 이러한 보상 로그 레코드를 사용하면 복구 단계에서 충돌이 발생하더라도 복구가 가능하다.[1]

3. 복구 (Recovery)

ARIES의 복구 알고리즘은 시스템 충돌 후 데이터베이스를 일관된 상태로 복원하기 위해 세 단계로 진행된다. 분석 단계에서는 로그 파일에서 필요한 정보를 계산하고, 재실행 단계에서는 충돌 당시의 정확한 상태로 데이터베이스를 복원하며, 이때 실행 중이었던 커밋되지 않은 트랜잭션의 모든 변경 사항을 포함한다. 실행 취소 단계에서는 커밋되지 않은 모든 변경 사항을 실행 취소하여 데이터베이스를 일관된 상태로 유지한다.[1]

3. 1. 분석 단계 (Analysis)

복구는 세 단계로 진행된다. 첫 번째 단계인 분석 단계에서는 로그 파일에서 필요한 모든 정보를 계산한다. 재실행 단계는 충돌 당시의 정확한 상태로 데이터베이스를 복원하며, 이때 실행 중이었던 커밋되지 않은 트랜잭션의 모든 변경 사항을 포함한다. 이후 실행 취소 단계는 커밋되지 않은 모든 변경 사항을 실행 취소하여 데이터베이스를 일관된 상태로 유지한다.

분석 단계에서는 충돌 시점의 더티 페이지 테이블(DPT, Dirty Page Table)과 트랜잭션 테이블(TT, Transaction Table)을 복원한다.

로그 파일(처음부터 또는 마지막 검사점부터)을 실행하면서 Begin Transaction 항목을 발견한 모든 트랜잭션을 TT에 추가한다. End Log 항목이 발견될 때마다 해당 트랜잭션이 제거된다. 각 트랜잭션의 마지막 시퀀스 번호도 유지 관리된다.

동일한 실행 동안 수정되었지만 아직 DPT에 없는 페이지를 발견할 때마다 새 항목을 추가하여 더티 페이지 테이블을 채운다. 그러나 이는 충돌 시점의 모든 더티 페이지의 상위 집합을 계산할 뿐이다. 페이지가 스토리지에 다시 기록되었는지 여부를 실제 데이터베이스 파일을 확인하지 않기 때문이다.

3. 2. 재실행 단계 (Redo)

DPT(더티 페이지 테이블)를 기반으로, 더티 페이지에 대한 로그 레코드를 재실행하여 충돌 시점의 데이터베이스 상태를 복원한다. 로그 레코드의 시퀀스 번호와 페이지의 시퀀스 번호를 비교하여, 필요한 경우에만 Redo를 적용한다.

로그 파일을 실행하면서 각 항목에 대해 수정된 페이지 P가 DPT에 존재하는지 확인한다. 만약 존재하지 않는다면, 데이터가 디스크에 영구적으로 저장되었기 때문에 이 항목을 다시 실행할 필요가 없다. 페이지 P가 DPT 테이블에 존재한다면, DPT의 시퀀스 번호가 로그 레코드의 시퀀스 번호보다 작은지 확인한다. 즉, 로그의 변경 사항이 마지막으로 영구적으로 저장된 버전보다 최신인지 확인한다. 그렇지 않다면 변경 사항이 이미 반영되었으므로 항목을 다시 실행하지 않는다.

만약 DPT의 시퀀스 번호가 로그 레코드의 시퀀스 번호보다 작다면, 데이터베이스 스토리지에서 페이지를 가져와 페이지에 저장된 시퀀스 번호를 로그 레코드의 시퀀스 번호와 비교한다. 페이지에 저장된 시퀀스 번호가 로그 레코드의 시퀀스 번호보다 작으면 페이지를 디스크에 기록해야 한다. 이 검사는 복구된 DPT가 실제로 변경 사항을 다시 적용해야 하는 페이지의 보수적인 상위 집합이기 때문에 필요하다.

위의 모든 검사가 완료되고 실패하면, redo(다시 실행) 작업을 다시 적용하고 페이지에 새로운 시퀀스 번호를 저장한다. redo 단계는 충돌로부터 복구하는 데에도 중요하며, redo가 동일한 페이지에 두 번 적용되지 않도록 한다.

3. 3. 실행 취소 단계 (Undo)

재실행(Redo) 단계를 거치면 데이터베이스는 충돌 시점의 정확한 상태를 반영한다. 그러나 커밋되지 않은 트랜잭션의 변경 사항은 데이터베이스를 일관된 상태로 복원하기 위해 취소해야 한다.

이를 위해 TT(트랜잭션 테이블)의 각 트랜잭션에 대해 로그를 역순으로 실행하며, 레코드의 이전 시퀀스 번호 필드를 사용한다. 각 레코드에 대해 변경 사항을 취소하고(Undo 필드의 정보를 사용하여) CLR(보상 로그 레코드)를 로그 파일에 기록한다. Begin Transaction 레코드를 만나면 해당 트랜잭션에 대한 End Log 레코드를 기록한다.

보상 로그 레코드를 사용하면 복구 단계에서 발생한 충돌 시에도 복구할 수 있다. 이는 생각보다 흔한 일인데, 복구 단계가 상당히 오래 걸릴 수 있기 때문이다. CLR은 분석 단계에서 읽고 재실행(Redo) 단계에서 다시 실행된다.

4. 검사점 (Checkpoints)

검사점은 복구 시간을 단축하기 위해 주기적으로 DPT와 TT를 로그 파일에 저장하는 메커니즘이다. 전체 로그 파일을 다시 스캔할 필요 없이, 검사점이 발견될 때까지만 역방향으로 실행하면 된다. 그 시점부터 로그 파일을 다시 정방향으로 읽어 들여 충돌 당시의 DPT와 TT를 복원할 수 있다. 그런 다음, 재실행(Redo)과 실행 취소(Undo)를 평소대로 진행할 수 있다.

검사점을 생성하는 간단한 방법은 검사점을 생성하는 동안 DPT와 TT의 변경을 막기 위해 전체 데이터베이스를 잠그는 것이다. 퍼지 로깅은 퍼지 로그 시작 레코드와 검사점 데이터를 준비한 후의 실제 검사점, 두 개의 로그 레코드를 작성하여 이를 우회한다. 두 레코드 사이에는 다른 로그 레코드를 생성할 수 있다. 복구하는 동안 유효한 검사점을 얻기 위해서는 두 레코드(퍼지 로그 시작 레코드와 실제 검사점)를 모두 찾아야 한다.

참조

[1] 논문 ARIES: A Transaction Recovery Method Supporting Fine-Granularity Locking and Partial Rollbacks Using Write-Ahead Logging 1992-03
[2] 웹사이트 Repeating History Beyond ARIES http://www.vldb.org/[...] C. Mohan, Proceedings of the 25th International Conference on Very Large Data Bases, Edinburgh, UK, September 1999.
[3] 웹인용 Repeating History Beyond ARIES http://www.vldb.org/[...] C. Mohan, Proceedings of the 25th International Conference on Very Large Data Bases, Edinburgh, UK, September 1999.
[4] 논문 ARIES: A Transaction Recovery Method Supporting Fine-Granularity Locking and Partial Rollbacks Using Write-Ahead Logging https://archive.org/[...] 1992-03



본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.

문의하기 : help@durumis.com