[Oracle 예제자료] DataBase File - OnLine Redo Log File

[정민이]

실무개발자를위한 실무교육 전문교육센터학원
www.oraclejava.co.kr에 오시면 보다 다양한 강좌를 보실 수 있습니다.

재실행 로그 파일(Redo Log File)


매우 중요한 파일로써 데이터베이스의 Transaction과 관련된 로그들 입니다. 만약 DB의 전원이 갑자기 나가 인스턴스 오류가 발생하면 정원이 나간 바로 그시점전 까지 복구를 위해 온라인 재실행 로그를 사용하게 되고, 데이터 파일이 있는 디스크가 못쓰게 되었다면 특정 시점으로의 복구를 위해 온라인 재실행 로그 뿐 아니라 아카이브된 재실행 로그를 활용해서 복구를 시도할 것 입니다.

모든 오라클 연산은 재실행 정보를 생성하여 온라인 재실행 로그 파일에 기록을 합니다. 예를 들어 테이블에 데이터가 추가 되거나 삭제 될 때 그 기록이 재실행 로그에 기록되어 지니다. 만약 테이블을 삭제 한다면 삭제한 결과가 재실행 로그에 기록되며 삭제된 테이블이 가지고 있던 데이터는 기록되지 않습니다. 한편 테이블을 삭제하기 위해 수행되는 오라클의 Recursive SQL(반복/재귀 SQL)은 재실행 정보를 생성 합니다. 예를 들면 오라클은 테이블 삭제를 위해 SYS.OBJ$ 테이블로부터 한 행을 제거 하는데 이로써 재실행 정보가 생성 됩니다.

어떤 연산들은 재실행 로그의 사용을 적게 하는 모드로 수행 될 수 있는데, NOLOGGING 속성을 가지는 인덱스를 생성 할 수 있습니다. 이것의 의미는 인덱스의 (초기) 생성은 로그를 기록하지 않지만 오라클이 수행하는 반복/재귀 SQL은 로그로 기록됨을 의미 합니다.

즉 이와 같이 인덱스가 존재하는 테이블에 대한 한 행의 삽입은 재실행 로그에 기록되지 않지만 SQL 삽입,삭제, 갱신 연산을 이용하여 인덱스를 변경 하는 것은 로그에 기록된다는 것입니다.

온라인 재실행 로그

모든 오라클 데이터베이스는 최소 2개 이상의 온라인 재실행 로그 파일을 가집니다. 이들 파일들은 모두 고정된 크기를 가지면서 돌아가면서 사용 됩니다.먼제 로그 1번 파일에 기록되고 이 파일이 가득차면 2번 파일, 또 가득차면 로그3번 파일로 옮겨서 기록 합니다. 이를 반복하면서 각 로그파일은 이전에 기록된 내용을 덮어 써 가면서 새로운 로그를 기록 합니다.

한 로그 파일로부터 다른 로그 파일로 전환하는 것을 로그 스위치(Log Switch)라고 하며 이러한 로그 스위치는 제대로 튜닝이 안된 DBMS에서는 그 순간 잠시 정체 할 수도 있습니다. 재 실행 로그는 복구를 위해 사용 되므로 덮어 써지기 전에 그 로그가 100% 필요 없다는 확신이 필요 합니다.

만약 오라클이 로그 파일의 내용이 더 이상 필요 없다는 것을 확신 하지 못한다면, 데이터베이스 연산은 순간적으로 정지되고 해당 하는 재실행 로그를 보호하는 데이터가 디스크에 안전하게 저장되어 있는지를 확인 할 것입니다. 일단 이것이 확인 되면 수행이 재개되며 재실행 로그 파일은 사용 되어 집니다. 여기서 체크 포인팅(Checkpointing)에 대해 이야기를 해야 되는데 온라인 재실행 로그의 사용 방법을 이해하기 위해서는 체크포인트, 데이터베이스 버퍼캐쉬의 동작 방법, DBWn(DataBase Block Writer) 이라 불리는 프로세스가 하는 일에 대해 알 필요가 있습니다.

데이터베이스 버퍼 캐시는 데이터베이스 블록들이 임시로 저장되는 장소로서 오라클의 SGA에 위치 하고 있습니다. 데이터 블록들이 읽혀 지면 데이터베이스 버퍼 캐시에 저장하여 향후 이 블록들을 디스크에서 다시 읽지 않도록 합니다.

데이터베이스 버퍼 캐시는 가장 중요한 성능 튜닝 디바이스로서 느린 물리적 디스크 I/O를 실제 보다 더욱 빠르게 만듭니다. 만약 블록의 내용이 변경 되면 데이터베이스 버퍼 캐시에 있는 블록들에게 적용 됩니다. 이러한 변경을 재실행 할 충분한 정보는 또 다른 SGA 데이터 구조인 재실행 로그 버퍼(Redo Log Buffer)에 기록 됩니다. 이때 커밋(Commit)을 한다면

오라클은 SGA에서 변경된 모든 블록들을 디스크에 기록하지 않는 대신에 재실행 로그 버퍼의 내용을 온라인 재실행 로그로 기록 합니다. 변경된 블록이 디스크에 기록되지 않고 데이터베이스 버퍼 캐시에 있는 동안에는 온라인 재실행 로그의 기록이 필요 합니다. 만약 커밋한 바로 얼마 후 전원이 나간다면 데이터베이스 버퍼 캐시는 완전히 비게 됩니다.(메모리 구조 이므로) 이 경우엔 변경된 내용은 온라인 재실행 로그 파일에 있어 DB 재구동시 오라클은 이전의 트랜잭션을 다시 수행하여 블록을 변경 시키고 커밋을 하게 됩니다. 그래서 변경된 블록이 디스크에 기록되지 않고 데이터베이스 버퍼 캐시에 있는 동안에는 온라인 재실행 로그를 덮어 써 버리면 안 되는 것입니다.

DBWn은 오라클의 백그라운드 프로세스로서 데이터베이스 버퍼 캐시가 가득 차 있는 상태에서 체크포인트를 수행 하기 위해 버퍼 캐시에 공간을 만드는 역할을 담당 합니다. 체크포인트는 손상된 블록(dirty/modified blocks)들을 데이터베이스 버퍼 캐시에서 디스크로 내리는 것입니다.

가장 일반적인 경우는 재실행 로그 스위치 입니다. 로그파일1이 가득차 로그파일2로 스위치 될 때 오라클은 체크 포인트를 시작 시킵니다. 이 시점에 DBWn은 로그 파일2에 의해서 보호된 변경된 블록을 모두 디스크로 내리기 시작하며 DBWn이 모두 디스크로 내리기 전까지 로그파일2를 사용 할 수 없습니다. 만약 DBWn이 모두 내리기 전에 로그파일1을 사용하려고 하면 다음과 같은 오류가 발생 합니다.

Thread 1 cannot allocate new log, sequence 66
Checkpoint not complete
Current log #2 seq# 65 mem# 0: c:\oracle\oradata\WINK\redo02.log
…
이 메시지가 나타날 때 데이터베이스는 잠시 정지되고 DBWn은 급히 체크포인트를 완료 합니다. 이 시점에 오라클은 모든 힘을 DBWn에게 주어 빨리 체크 포인트가 끝나도록 합니다.
 
이와 같은 현상은 잘 튜닝된 DBMS에서는 잘 발생하지 않도록 원할 것이며 DBA의 입장에서는 체크포인트가 완료 되기 전에 온라인 재실행 로그 파일이 사용되지 않도록 충분히 큰 로그파일을 원할 겁니다. 만약 앞의 메시지를 자주 보게 되면 충분한 온라인 재실행 로그를 할당하지 않았거나 DBWn이 효율적으로 동작하도록 튜닝이 필요하다는 것을 의미 합니다.
 

 온라인 재실행 로그의 개수와 크기를 정할 때 고려해야 하는 요소

1.대기 데이터베이스(standby database) : 만약 대기 데이터베이스를 활용하고 있다면 재실행 로그들이 가득 찰 경우 대기 데이터베이스로 보내어 지기 때문에, 대부분 크기는 작지만 많은 수의 재실행 로그들이 필요 합니다.

2.동일한 블록을 변경하는 사용자가 많은 경우 : 이 경우에는 대용량의 온라인 재실행 로그 파일이 필요 합니다.모든 사람들이 동일한 블록을 변경 하기 때문에 이 블록들을 디스크에 기록하기 전까지는 재실행 로그가 다시 사용되면 안 되는 것이다. 각각의 로그스위치는 체크포인트를 발생 시키기 때문에 로그스위치가 자주 일어나지 않게 할 필요가 있습니다.


3.복구 평균 시간 : 만약 복구 시간이 최대한 단축되어야 한다면 동일한 블록을 변경하는 사람이 많다고 할지라도 적은 용량의 온라인 재실행 로그 파일이 필요 합니다. 복구를 위해 하나의 큰 로그파일을 처리하는 것보다 적은 양으로 여러 개의 로그 파일을 처리하는 것이 시간을 줄일 수 있습니다. 적은 크기의 온라인 재실행 로그를 사용하면 빈번한 로그스위치로 인한 체크포인트가 발생하여 성능은 떨어지지만 복구를 위한 사간은 줄어 듭니다.


아카이브된 재실행 로그 파일(Archived Redo Log File)

오라클데이터 베이스는 NOARCHIVELOG와 ARCHIVELOG의 두가지 모드 중 하나로 동작 합니다. 대부분 ARCHIVELOG로 운영되지 않는 시스템은 생산시스템이 아닙니다. 왜냐하면 ARCHIVELOG로 운영되지 않으면 언젠가는 DB의 데이터는 잃어 버리게 됩니다. 단지 TEST 용도로 쓰이는 DB만 NPARCHIVELOG로 돌려야 합니다.

이 두 모드의 차이는 오라클이 온라인 재실행 로그를 처리하는 방법에 따라 차이가 납니다. “재실행 로그를 재사용 할 때, 재실행 로그의 복사본을 유지하는가? 아님 덮어 써버리는가?” 입니다. ARCHIVELOG모드인 경우 온라인 재실행 로그를 덮어 쓰기 전에 HDD에 정해진 ARCHIVE DESTINATION 폴더에 파일로써 보관을 하는 겁니다.

DB가 NOARCHIVELOG로 운영되며 일주일에 한번 매주 토요일에 백업을 한다고 가정을 하겠습니다. 일주일 동안 몇 백개의 재실행 로그를 생성한 후 금요일 오후에 HDD 오류가 생겼다고 할 때 선택할 수 있는 방법은 다음의 두가지중 하나 입니다.

오류가 발생한 디스크에 있는 테이블스페이스를 없앰… 이 경우 해당 테이블스페이스의 데이터는 모두 날아가게 됩니다. 만약 SYSTEM 테이블스페이스가 영향을 받게 되면 이 방법은 사용 할 수가 없습니다.

지난 토요일의 백업 데이터를 이용하여 복구… 이 경우 이번 주 작업한 것은 잃어버리게 되는 겁니다.

결론적으로 중요한 데이터베이스 시스템은 반드시 ARCHIVELOG 모드로 운영 되어야 합니다.