redo and undo

1. 재실행(REDO)

l  REDO log file 은 DB의 복구 목적으로 사용되는 Transaction log 로써, 인스턴스나 미디어 실패시 사용된다.

l  재실행 로그는 online 과 archived 의 두 가지 유형으로 유지된다.

l  재실행 로그는 적어도 2개의 온라인 재샐행 로그 파일을 가지며, 보통 2-3개의 로그 파일로 구성되어 순환구조로 기록된다.

l  온라인 재실행 로그 파일이 다 차면 ARCH 프로세스는 다른 곳에 온라인 재실행 로그 파일의 복사본을 만든다.

l  아카이브된 재실행 로그 파일들은 데이터베이스 트랜잭션의 이력 정보이다.

l  재실행은 데이터베이스를 파일 시스템과 구별하는 중요한 요소이다.

2. COMMIT 의 의미

l  DB에서는 데이터를 이미 변경하였기 때문에 트랜잭션의 크기와 무관하게 커밋의 응답시간은 일정하다. (커밋이 실제로 대량의 작업을 하는 것은 아니다)

l  트랜잭션이 가져야 할 만큼의 크기를 가지도록 해야 한다. (개발자들이 논리적 작업 단위가 수행된 후 커밋하지 않고, 각 행마다 커밋하는 것은 잘못이다.)

1) Commit 이전에 실행된 연산

-       롤백 세그먼트 레코드들은 이미 SGA에 생성되었다.

-       변경된 데이터 블록들이 이미 SGA에 생성 되었다.

-       위의 두 항목을 위한 버퍼 재실행(buffered redo)이 SGA에 생성되었다.

-       위의 세 항목의 크기와 소비된 시간에 따라 위의 데이터의 일부분이 이미 디스크에 기록되었을 수도 있다.

-       모든 잠금들이 확보되었다.

2) Commit 시 발생되는 동작

-       트랜잭션을 위한 SCN(System Change Number) 를 생성한다.

-       LGWR가 아직 남아 있는 버퍼 재실행 로그 엔트리를 모두 디스크에 기록하고, 온라인 재실행 로그 파일들에 SCN을 기록한다. V$TRANSACTION 뷰에 관련 레코드가 삭제된다.

-       세션에 의해 취득된 모든 잠금들이 해제되고, 잠금을 기다리고 있던 모든 사람들이 자유롭게 된다.

-       트랜잭션이 변경한 블록들이 여전히 버퍼 캐시에 존재하면 제거된다. (블록 클린아웃)

SCN (System Change Number) : 오라클이 트랜잭션들의 순서를 보증하고 실패로부터 복구를 가능하게 하기 위해서 사용하는 단순한 시간 처리 방법.

또한 SCN은 데이터베이스에서 읽기 일관성과 체크포인트를 보장하는데 사용된다. 누군가 커밋할 때마다 SCN은 1씩 증가한다.

3) LGWR 연산

Commit시 가장 긴 연산은 LGWR에 의해서 수행되는 활동이다.

(이는 물리적 디스크 I/O이기 때문이다.)

사용자가 작업을 수행하는 동안 LGWR은 백그라운드로 재실행 로그 버퍼의 내용을 디스크에 기록하므로써, 재실행 정보를 한 번에 기록하기 위하여 너무 오랫동안 커밋이 대기하지 않도록 해준다.

LGWR이 디스크에 기록되는 시점

-       3초마다

-       1/3 혹은 1MB가 가득 채워졌을 때

-       트랜잭션 커밋시

  

3. ROLLBACK 의 의미

l  롤백은 기존의 작업들을 물리적으로 취소시켜야 하므로 롤백의 수행 시간은 변경된 데이터 양에 비례한다.

l  롤백은 오랜 시간 동안 수행한 작업을 취소하는 것이기 때문에, 롤백 역시 많은 작업을 수행하는 많은 비용을 요구하는 작업이다.

1) Rollback 시 발생되는 동작

-       롤백 세그먼트로부터 데이터를 읽음으로써 기존에 만들어진 모든 변경들을 취소시킨다.

-       세션에 의해 취득된 모든 잠금들이 해제되고, 잠금을 기다리고 있던 모든 사람들이 자유롭게 된다.

4. 재실행의 생성

l  재실행의 생성은 데이터베이스의 성능에 영향을 준다.

l  redo size 분석: v$mystat, v$statname

1) 명령문(INSERT, UPDATE, DELETE) 에 따른 재실행 양

-       Insert : 영향받은 행의 수에 비례하여 재실행 양이 증가한다.

-       Update : 영향받은 행의 수에 비례하여 insert시의 2배에 달하는 재실행 양이 증가한다

-       Delete : insert시와 비슷한 양으로 증가함.

-       이 때, insert 시에는 전체 영향받는 행들에 대하여 한꺼번에 실행할 때 보다 한번에 한 건씩 실행할때의 재실행 양이 더 증가되었다.

커밋후의 재실행양이 커밋전보다 크다.

2) 재실행 사이즈 예측

-       트랜잭션의 크기를 예측한다. 사용자는 얼마나 많은 데이터를 수정하는지 예측한다.

-       변경하려는 행들의 숫자에 비례하여 10%-20% 오버헤드를 추가한다. 행이 많을수록 더 작은 오버헤드가 필요하다.

-       갱신의 경우에는 2배의 재실행 양이 필요하다. (이는 상황에 따라 다르다.)

5. 재실행 로그의 생성 거부

1) ARCHIVELOG 모드

-       NOARCHIVELOG 모드

-       ARCHIVELOG 모드

2) ARCHIVELOG 모드 에서NOLOGGING 옵션

-       재실행이 완전히 생성되지 않도록 할 수는 없으나 이전보다 매우 적은 양으로 생성된다. (모든 data dictionary 연산들은 로깅 모드에 상관없이 로그를 남긴다.)

-       NOLOGGING 이후의 모든 연산들에 의해 생성되는 재실행은 막지 않는다.

-       SQLLDR을 이용한 Direct path load 혹은 /*+append*/ 를 이용한 direct path insert 등과 같은 특별한 연산들은 로그되지 않으나 이외의 모든 연산들에 대한 로그는 남는다.

-       Oracle 7.3 에서는 nologging 키워드 대신 unrecoverable 을 사용해야 한다.

-        

3) NOLOGGING 모드에서 수행되는 연산

-       인덱스 생성과 ALTER

-       /*+append*/ 힌트를 통하여 ‘직접 경로 삽입’을 이용한 대량의 삽입

-       로그되지 않아야 할 큰 객체에 LOB연산들

-       Create table as select 를 통한 테이블 생성

-       Move와 split와 같은 다양한 alter talbe 연산들

-       Truncate (이 연산은 항상 nologging 모드 내에 있다.)

6. 새로운 로그를 할당할 수 없는 에러

l  데이터베이스가 온라인 재실행 로그 파일을 재사용하려고 시도하였으나 사용할 수 없음을 발견할 때마다 서버의 alter.log checkpoint not complete 에러 발생

l  재실행 로그를 통하여 보호되는 데이터를 DBWR가 체크포인팅하는 것을 아직 마치지 안았을 때나 ARCH가 아카이브 대상으로 재실행 로그 파일을 복사하는 것을 마치지 않았을 시 발생

l  최적화 되지 않은 초기 데이터베이스에서 목격됨.

해결방법

-       DBWR를 빠르게 하라.

-       재실행 로그 파일들을 더 추가하라.

-       더 큰 크기로 로그 파일들을 재작성하라.

-       체크포인트가 보다 빈번하게 그리고 보다 연속적으로 발생하게 하라.

7. 블록 클린아웃

데이터 잠금이 블록 헤더에 저장되는 데이터의 속성으로 관리됨으로써 발생되는 부작용은 블록이 다음에 접근될 때 cleanout (트랜잭션 정보를 제거)을 해야 할지도 모른다는 것이다.

이는 재실행을 발생시키고 블록이 손상되게 한다.

또한 간단한 select 문이 재실행을 생성할 수 있고, 다음 체크포인트와 함께 디스크에 많은 블록들이 기록되게 한다는 것이다.

Commit cleanout : commit 의 처리단계에서 블록들이 SGA내에 있다면 그 블록들을 재방문하여 그 블록들이 다른 사람들에 의해서 변경되지 않은 상태이고 접근이 가능하면 블록을 깨끗하게 한다.

8. 로그 경합

로그 파일 대기의 가장 일반적 원인

-       매우 느린 저장 장치에 재실행을 두는 것

-       재실행을 다른 파일들과 같이 동일한 장치에 저장

-       버퍼 방식으로 장치들을 마운트

-       RAID-5 같은 느린 기술로 재실행 저장