[DB] 데이터베이스 Redo와 Undo

트랜잭션 특성 ACID

A(Atomicity) 원자성

• DBMS는 수행 중인 트랜잭션에서 데이터를 일부만 변경하고 나머지는 수행하지 않은 채 커밋 할 수 없습니다.

C(Consistency) 일관성

• 트랜잭션에 의해 데이터 간의 일관성이 어긋나서는 안된다.

I(Isolation) 고립성

• 트랜잭션끼리는 고립되고 독립되어 있다

D(Durability) 지속성

• 커밋한 트랜잭션은 장애가 발생하더라도 데이터는 반드시 복구되어야 한다

 

데이터베이스의 중요한 특징인 커밋한 데이터를 지키는 특성을 구현하기 위해서는 로그(변경 로그)를 채용하여 성능과 지속성을 양립시킵니다. REDO로그에 데이터를 한꺼번에 기록하는 것으로 I/O의 횟수가 줄어들고, 시퀀셜 액세스를 사용하여 I/O에 소모되는 시간을 줄였기 때문입니다. 또한 I/O 크기는 커지지만, 첫머리를 찾아가는 작업의 횟수는 변하지 않으므로 I/O 시간이 지연되지 않습니다.

 

 

Redo와 Undo

REDO로그란 데이터의 변경 기록을 기록한 것이고, UNDO로그는 어떻게 하면 과거의 상태로 돌아갈 수 있는지에 관한 정보입니다.

그러나 이러한 개념만으로는 이해가 쉽지 않기 때문에 한가지 예를 들어 생각해보겠습니다.

 

A군이 현재 집에 있는 상태라고 가정을 해보겠습니다.

그리고나서 A군이 학교로 이동을 하였습니다.

그러면 A군은 집 → 학교로 상태가 변경 되었기 때문에 REDO 로그는 A군이 학교에 갔다는 변경 기록을 저장하게 됩니다.

 

그런데 만약 A군이 학교로 이동하기 전의 상태로 되돌리려고 하면 REDO 로그만으로는 학교에 오기 전에 어디에 있었는지 알 수 가 없습니다. 그래서 UNDO 로그를 통해 A군를 집으로 돌려놓는다라는 정보를 저장해줍니다.

 

이렇게 REDO로그를 통해 과거의 데이터를 최신데이터 쪽으로 흐르게 하는 것을 롤 포워드(roll-forward)라고 하고, UNDO 로그를 통해 과거의 상태로 되돌리는 것을 롤백(rollback)이라고 합니다.

 

REDO의 구조

그렇다면 REDO 로그의 구조는 어떻게 되어 있을까요??

1. 서버 프로세스가 REDO 로그 버퍼에 REDO 로그를 넣는다.
2. LGWR 프로세스는 서버 프로세스의 의뢰를 받거나, 자발적으로 REDO 로그 버퍼에 있는 REDO로그를 REDO 로그 파일에 기록함
3. ARCH 프로세스가 아카이브 REDO 로그파일로 옮긴다.

 

REDO 로그용 메모리로서 REDO 로그 버퍼가 공유 메모리에 존재합니다. REDO 로그를 디스크에 REDO 로그 파일로 기록하는 것은 LGWR이라고 불리는 프로세스가 수행합니다.

또한 REDO 로그 파일은 개수가 한정(일반적으로 한 세트에 3개)되어 있으며, 크기도 제한되어 있으므로 REDO 로그를 계속 보관하고 있을 수는 없습니다.

그래서 아카이브 REDO 로그파일이라는 오랫동안 REDO 로그를 보관해두기 위한 파일이 존재합니다. REDO 로그 파일은 REDO 로그의 일시적인 보관 창고이며, 아카이브 REDO 로그 파일이 오랜 시간 보관할 수 있는 본격적인 보관 창고입니다.

REDO 로그 파일은 매우 중요한 파일이므로 반드시 다중화해야 합니다. 일반적으로 REDO 로그 그룹을 여러 개의 세트로 만들고, 그룹 안에 멤버(REDO 로그 파일)를 추가합니다. 여기서 다중화는 그룹을 늘리는 것이 아닌 멤버를 늘리기 때문에 주의해야합니다.

 

 

REDO 효과

REDO 로그를 통해 데이터베이스는 많은 장점을 얻을 수 있습니다.

• 병렬 처리를 가능케 하고 높은 처리량을 실현
  • 기본적으로 여러 개의 서버 프로세스는 데이터를 동시에 변경할 수 있습니다. (단, 같은 데이터는 제외)
  • REDO 로그를 기록하는 데에서도 LGWR은 여러 서버 프로세스의 REDO 로그를 한꺼번에 기록하기 때문에 높은 처리량을 구현할 수 있습니다.
• 응답 시간(response time)을 중시
  • 커밋할 때 블록을 디스크에 기록하지 않고 REDO 로그에 기록하는 것으로 빠른 커밋을 구현할 수 있습니다.
  • 1차로 REDO 로그에 기록을 한뒤 추후에 디스크에 기록을 합니다.
• 커밋한 데이터는 지킴
  • 장비에 장애가 발생하여 DBWR이 데이터를 기록할 틈도 없다고 가정하더라도 그 후에 REDO 로그와 데이터 파일에 남아있는 오래된 데이터를 사용해서 데이터를 복구할 수 있습니다.

 

UNDO 구조

데이터가 변경되면 UNDO 정보가 생성되며, 생성된 UNDO 정보는 세그먼트에 보관됩니다. 세그먼트에 보관된다는 점으로 인해 UNDO 정보가 테이블스페이스들 중 어딘가에 보관된다는 사실을 알 수 있습니다. UNDO 정보가 보관되는 테이블스페이스를 UNDO 테이블스페이스라고 부릅니다. UNDO 테이블스페이스에는 여러 개의 UNDO 세그먼트가 생성됩니다.

기본적으로 트랜잭션과 UNDO 세그먼트가 일대일로 대응하기 때문입니다. 한 트랜잭션이 한 UNDO 세그먼트를 사용하기 때문에 필요할 때는 세그먼트의 수를 늘려줍니다.

 

1번과정

UNDO 세그먼트는 링 버퍼(ring buffer)입니다. 링 버퍼는 순차적으로 데이터를 보관하고 한 바퀴 돈 후 이전 데이터를 덮어쓰는 구조입니다. 링 버퍼는 조금 지나면 데이터가 덮어쓰이는 버퍼이지만, 커밋하지 않는 데이터는 덮어써지지 않습니다. 가장 오래된 UNDO 정보를 덮어쓸 수 없거나, 덮어쓰고 싶지 않을때는 UNDO 세그먼트를의 크기를 늘려줍니다.

 

 

다양한 상황

읽기 일관성을 지원

읽기 일관성이란, 데이터를 검색할 때 어떤 시점의 데이터를 보여주는 기능을 말합니다.

예를 들어, 검색을 시작한 후에는 다른 세션에서 변경한 데이터를(커밋을 했더라도) 읽지 못하게 하고, 검색 중에는 계속해서 검색을 시작한 시점의 데이터를 보여주는 것을 말합니다.

읽기 일관성은 데이터가 변경된 시점을 확인하고, 검색을 시작한 후에 변경된 데이터일 떄는 UNDO를 사용해서 과거의 데이터를 메모리 위에 재현합니다.

ORA-1555 에러 발생

ORA-1555 에러는 과거의 데이터를 보려 했으나 필요한 정보가 이미 없어졌다 라는 것을 의미합니다.

예를 들어 데이터를 검색하는 데 24시간이 걸릴 때 검색을 시작하고서 1시간 뒤 다른 세션이 어떤 데이터를 변경하고 커밋했다고 가정하겠습니다. 그리고 몇 시간 후에 '해당 데이터에 관한 UNDO 정보가 덮어써져 사라졌다'고 가정합니다. 그 후에 검색을 시작하고 20시간이 지난 후 데이터가 변경된 부분을 읽기 시작 했을 때, 오라클은 데이터가 변경되었으므로 검색을 시작했을 때의 데이터를 재현하려고 합니다. 하지만 UNDO 정보가없어져 필요한 데이터를 재현해서가져올 수 없으므로 ORA-1555(snapshot too old)라는 에러가 발생하며 검색에 실패합니다.

ORA-1555 에러가 발생하지 않도록 하기 위해서는 UNDO 정보를 좀 더 길게 유지할 수 있도록 설정해야 합니다. 초기화 파라미터 undo_retention을 사용해서 UNDO 보존 기간의 하한값을 지정할 수 가 있지만, 이 파라미터는 UNDO 테이블스페이스의 자동 확장 기능이 ON으로 되어 있을 때만 유효합니다. undo_retention을 설정하고 싶을 때는 UNDO 테이블 스페이스의 자동 확장 기능을 ON으로 변경하고, 필요하다면 MAXSIZE 값을 설정해줍니다.

여기서 주의할 점은 UNDO 테이블스페이스가 부족할 때는 undo-retention에서 지정한 시간보다 적더라도 UNDO 정보가 삭제됩니다. 따라서 v$undostat의 정보를 토대로 UNDO가 10분 동안 얼마나 생성되는지를 파악한 후, undo_retention을 크게 했을 경우에 UNDO 테이블스페이스가 감당할 수 있는지를 검토하고 값을 변경해야 합니다.

인스턴스 복구 시의 동작

컴퓨터 장애가 돌발적으로 발생 했을 때 오라클은 어떻게 데이터를 복구할까요??

장애가 발생한 컴퓨터의 데이터 파일에는 조금 오래된 데이터밖에 없을 것이므로 REDO 로그가 활약합니다. 오라클은 데이터 파일에 REDO 로그를 적용하고 데이터를 최신 상태로 갱신합니다. 이때 커밋하지 않은 데이터를 어떻게 처리할지 막막해 보입니다. 왜냐하면 REDO 로그 파일에는 커밋하지 않은 REDO 로그의 내용도 함께 기록 되어 있기 때문입니다. 그러나 커밋하지 않은 트랜잭션은 REDO 로그에도 커밋 정보가 존재하지 않습니다. 따라서 UNDO 정보를 사용해서 커밋 정보가 존재하지 않은 트랜잭션들을 구분해내어 롤백 처리를 수행합니다.

여기서 'UNDO는 테이블스페이스에 보관되어 있으니까 디스크에 실시간으로 기록하지는 않는 거 아닌가?'라는 의문을 가지는 분들도 있을 것으로 생각합니다. 실은 UNDO가 변경되는 정보 역시 REDO 로그에 들어가 있기 때문에 롤 포워드함으로써 UNDO를 최신 상태로 만들 수 있습니다.

오라클을 기동할 때 이런 방식으로 자동 수행되는 복구를 '인스턴스 복구(instance recovery), 충돌 복구(crash recovery)'라고 부릅니다.