RBS 손상 진단과 복구 방법(ORA-600[4137],ORA-600[4137],ORA-2587, ORA-1545)
========================================================================

(1) 롤백 세그먼트 손상의 증상

1. alert log 화일에서 ORA-00600 [4137] 혹은 ORA-00600 [4193] 발견
2. 특정 블럭에 ORA-01578 발생
3. 인스턴스 기동 시 ORA-01545 발생

만일 데이터베이스가 오픈 상태이면 dba_rollback_segs를 조회하여 특정
롤백 세그먼트의 상태가 "needs recovery"인 것을 발견할 수 있다. 이 경우
가장 우선 해야 할 작업은 해당 손상의 대상이 롤백 세그먼트인지 혹은
롤백과 관련한 데이타 세그먼트(테이블 혹은 인덱스)인지를 파악하는 일이다.

(2) 손상의 대상 파악 및 조치 단계

1. 문제와 관련된 롤백 세그먼트 확인
2. 해당 롤백 세그먼트의 트랜잭션 테이블 덤프 확인
3. 해당 롤백 세그먼트를 사용 중인 undo 정보의 dump 확인
4. 손상된 익스텐트 파악
5. 조치 사항
- 만일 해당 롤백 세그먼트의 모든 트랜잭션이 커밋 상태이면: 롤백
세그먼트 삭제함.
- 커밋 상태인 트랜잭션이 존재하면 : 해당 테이블 혹은 인덱스 삭제 후,
롤백 세그먼트도 삭제함.
- 활성화 중인 트랜잭션을 파악하지 못하거나 해제하지(resolved) 못하면:
데이터베이스 export 후 재생성함.

(3) 롤백 세그먼트 손상에 대한 복구 사례

1. 데이터베이스가 기동되어 있는 경우, 문제의 롤백 세그먼트의 트랜잭션
테이블과 진행 중인 트랜잭션의 언두 레코드의 덤프를 확인한다.

2. 데이터베이스가 종료되어 있고 기동이 가능하지 않은 경우, 다음 작업을
수행한다.

- init ora 화일에 다음 이벤트를 설정한다. (00015, "Undo Segment
Recovery")
event="10015 trace name context forever, level 10"

- 데이터베이스를 기동한다. 오류가 계속하여 발생하더라도 위 이벤트는
user_dump_dest에 모든 롤백 세그먼트에 대하여 복구 전후의 트랜잭션
테이블 dump를 출력할 것이다.

- initSID.ora 파라메터 rollback_segments를 주석 처리하고,
데이터베이스를 다시 기동한다.

- 문제가 지속되면 손상된 것으로 보이는 롤백 세그먼트를 아래의 다음
파라미터에 포함시킨 후 다시 기동한다.

offlinerollback_segments = (r01)
(주의) 동일한 롤백 세그먼트를 rollback_segments 파라미터에도 동시에
포함시키지 말아야 한다.

- 문제가 지속되면 손상된 것으로 보이는 롤백 세그먼트를 아래
파라미터에도 추가로 포함시킨 후 다시 기동한다.

corruptedrollback_segments = (r01)
(주의) 동일한 롤백 세그먼트를 rollback_segments 파라미터에도 동시에
포함시키지 말아야 한다.

- 데이터베이스의 기동이 완료되면 "(5) 트랜잭션 테이블과 undo 레코드
덤프 과정"에 따라 롤백 세그먼트의 트랜잭션 테이블과 트랜잭션 undo
레코드의 덤프를 분석한다.

3. 롤백 세그먼트 화일이 삭제되가나 롤백 세그먼트 헤더에 손상이 있는
경우는 트랜잭션 테이블의 dump 생성 방법이 없으므로,
- 모든 롤백 세그먼트를 corruptedrollback_segments 파라미터에 지정한 후
데이터베이스를 기동한 후 export 받은 후 데이터베이스를 재생성한다.

(4) Underbar(_) 파라미터의 차이점

1. offlinerollback_segments

만일 롤백 세그먼트가 offlinerollback_segments 파라미터에 지정되어
있다면 해당 트랜잭션 테이블은 block clean-out을 위한 읽기가 가능한
상태이므로 이전 트랜잭션이 커밋 상태라면 delayed block clean-out이
가능하다. 그러나 이전 트랜잭션이 아직 커밋 상태가 아니라면 해당
블럭에 대한 consistent 뷰가 생성은 되지만, 해당 데이터 블럭에 대한
수정은 가능하지 않게 되는 상태가 된다.

2. corruptedrollback_segments

롤백 세그먼트가 offlinerollback_segments 파라미터에 지정되어
있다면 해당 트랜잭션 테이블은 읽기가 불가능한 상태로 유지되며, 모든
트랜잭션은 커밋한 것으로 간주되고 block clean-out이 발생한다. 하지만
실제로 커밋되지 않은 트랜잭션에 대해서는 consistent read 이미지를
생성할 수 없기 때문에 논리적으로는 손상을 입은 상태이다.

(5) 트랜잭션 테이블과 undo 레코드 dump 과정

1. 문제의 롤백 세그먼트를 확인한다.

SQL> SELECT status, segment_name, owner FROM dba_rollback_segs;

2. 만일 오류 번호가 ORA-01578이면 file#, block#를 이용하면 문제의
세그먼트도 알 수 있다.

SELECT segment_type, segment_name, owner
WHERE file_id =
AND BETWEEN block_id AND block_id + blocks - 1;

3. 트랜잭션 테이블 덤프의 예제를 아래에 나타내었다.

TRN TBL::
...
12 : state: 90 cflg: 10 wrp: 9cc uel: 19 scn: 0.fd56edfd ...
...

4. State가 *90*(invalid)이고 cflg가 "10"(Rollback failed on this TX
- mark SMON for recover )이므로 커밋되지 않은 트랜잭션이 존재한다는
것을 알 수 있다.

5. 언두 블럭(DBA 0x28006550)의 dump를 생성하여 조사한다. 만일
트랜잭션의 flg: 값이 C--- 혹은 C-U-으로 존재하면, 커밋되지 않은
트랜잭션이 없다는 것을 의미하므로 해당 롤백 세그먼트는 삭제한다.

...
*-----------------------------
* Rec #0x1 slt: 0x17 obj: 1835 (0x0000072b) tablespace: ...
* Layer: 11 (Row) opc: 1 rci 0x00 dba: 0x00000000
*-----------------------------
uba: 0x08000a0e.0717.0f ctl max scn: 0x0551.858f1cce prv tx ...
KDO undo record:
KTB Redo, op: L itl: xid: 0x0009.007.00000113 uba: ...
flg: C--- lkc: 0 scn: ...
KDO Op code: URP xtype: XA bdba: 0x14000cc9 hdba: ...
itli: 1 ispac: 0 maxfr: 1177
tabn: 0 slot: 0(0x0) flag: 0x2c lock: 0 ckix: 208
ncol: 1 nnew: 1 size: 0
col 0: [ 2] c1 02
...


6. 만일 flg: 값이 "C---"이면 커밋이 정상적으로 종료된 상태이므로 데이타
세그먼트를 재생성할 필요가 없지만, "C-U-" 값을 가지면 트랜잭션의
SCN을 추정하여 가장 최근의 롤백 세그먼트 버젼을 유지하고 있는
것이어서 커밋이 정상적으로 종료된 상태라 볼 수 없으므로 데이타
세그먼트를 반드시 재생성하여야 한다.

7. 끝으로 복구 작업이 종료되면 롤백 세그먼트와 관련된 파라메터를
정상적으로 복원(_offline_rollback_segments와
corruptedrollback_segments 삭제하고 rollback_segments 재지정)하여
데이터베이스를 재기동한다.