2012.02.08 백업&복구 6번째( Instance Recovery원리, redo log원리, change vector, latch, 2가지 SCN, checkpoint종류, FAST_START_MTTR_TARGET, Shared redo Strand)

내용출처 :  http://jigi.net/4239 
** 위 포스팅을 그대로 긁어올 수 있게 해주신 해당 사이트 운영자 지기님 감사드립니다.

1. Instance Recovery 
데이터베이스가 비정상적으로 종료되어 STARTUP 할 때 SMON이 redolog file과 Undo Segment 정보를 가지고 데이터 복구
하는 과정을 말한다. 이 때 복구해야할 데이터는 모두 Redolog 파일에 기록되어 있어야 하며, 복구할 데이터가 Archive 파일에도 있을 경우 자동복구(SMON이 자동실행)는 실패하고 수동복구(DBA가 수행)가 필요하게 된다.


2. RedoLog의 생성 및 기록원리
  가. DML 작업 발생
  나. 필요블럭 DB Buffer Cache에 로드 -> Block Lock(page fix)
  다. PGA에서 Redolog Change Vector 생성
  라. redo copy latch 획득
  마. redo allocation latch 획득
  바. redolog buffer 에 Change Vector 기록
  사. LGWR이 redolog buffer의 내용을 redolog 파일에 기록
      (buffer가 1/3이상이 찼을 경우, 1M가 넘었을 경우, 3초에 한 번)

참고 : Change Vector
Change Vector에는 변경 전 데이터와 변경후 데이터가 모두 기록되는데, 그 이유는 비정상적인 서버종료 시 Roll forward와 Rollback 작업을 수행하기 위해서이다. Rollforward는 사용자가 commit 하였지만 비정상적인 서버종료로 datafile에 기록하지 못한 데이터를 저장하는 행위이며, rollback는 commit하지 않았거나 rollback 명령어로 해당 트랜잭션을 취소했을 때 원래대로 데이터를 되돌리는 행위이다.

참고 : latch
Latch는 SGA의 공유 데이터구조를 보호하기 위해서 사용되는 기법으로 빨리 획득되고 풀리는 Lock의 일종이다. 한 순간에 하나 이상의 프로세스가 동시에 같은 메모리를 접근하는 것을 방지하는데 사용된다. 
추가정보 : http://blog.naver.com/PostView.nhn?blogId=dangtong76&logNo=140064903533

참고 : latch의 경합 및 관리
Latch는 모든 메모리영역(DB Buffer Cache, Redolog, Shared pool 등)에 각각 존재하며 갯수도 다르다. Latch는 여러개가 존재하거나 1개만 존재할 수 도 있다. Latch가 1개일 경우 이것을 차지하기 위한 프로세스의 경합이 발생한다. 이러한 경합이 자주 발생할수록 서버의 성능은 저하된다. 그러므로 이를 해결하기 위한 방법이 여러가지 고안되었는데 그 중 shared redo strand가 있다. shared redo strand는 redolog buffer를 여러개의 공간으로 나누어 각 공간별로 redo allocation latch를 할당해주는 것을 말한다.(이 기능이 도입되기 전에는 redo allocation latch는 1개였다), 이후 shared reo strand의 확장버전인 private redo strand 기능을 도입하였다. 이 기능은 shared pool에 자신만의 private redo strand 영역을 만들어 그곳에 change vector를 생성하고 필요할 경우 LGWR이 redo log 파일에 기록하는 것을 말한다. 이를 zero copy라고 부른다. 이처럼 latch의 경합을 줄이기 위해 많은 기술이 계속 발전하고 있다.

참고 : SCN(System Commit Number) Vs SCN(System Change Number)
- System Commit Number : Commit 가 발생하면 해당 트랜잭션은 고유한 번호를 부여받는데 이를 SCN이라 한다. SMON이 kcmgas 라는 함수를 사용하여 관리한다. scn_base(4byte) + scn_wrap(2byte)으로 구성
- System Change Number : 데이터파일, 리두로그파일, 컨트롤파일의 동기화를 맞추기 위해 사용,
scn_base(4byte) + scn_wrap(2byte) + scn_sequence(1byte)로 구성, scn_sequence는 여러개의 서버프로세스가 동일한 블록을 변경하려고 할 때 이를 구분하기 위해 사용한다.

3. Commit Write
  가. Commit 발생 시 LGWR이 해당 트랜잭션을 기록하는 것, 이 과정은 4가지 방식이 있다.
    - WAIT : 변경된 트랜잭션이 리두로그파일에 기록될 때까지 서버프로세스, SMON등이 기다림
    - NOWAIT : WAIT와는 반대로 서버프로세스나 SMON등이 기다리지 않음(다음 작업을 바로 수행) 
    - IMMEDIATE : COMMIT 발생 시 리두로그파일에 바로 기록
    - BATCH : COMMIT이 발생하더라도 일정시간동아 모아서 한번에 기록
  나. 일반적으로 위 4가지 방식 중 2개씩 혼합하여 사용(IMMEDIATE+WAIT, IMMEDIATE+NOWAIT 등)
  다. BATCH나 NOWAIT와 같이 리두로그파일에 기록작업이 끝나지 않아도 서버프로세스나 SMON등이 다른 작업을 할 수 있도록 하는 방식을 비동기식 커밋(Asynchronous Commit)라고 한다.

참고 : 비동기식 커밋방식(NOWAIT, BATCH)의 장단점
- 데이터의 안정성은 높아지나 DISK I/O가 발생하므로 서버의 성능이 저하됨
- OLTP 환경에서는 자제하는 것이 좋음

4. Checkpoint의 종류
  가. Database / Global Checkpoint : DB Buffer Cache에 있는 모든 Dirty Buffer의 내용을 데이터파일에 저장
  나. Thread checkpoint / Logical Checkpoint : RAC환경하에 사용, 해당 Thread내의 저장되지 않은 Dirty Buffer의 내용을 데이터파일에 저장
  다. Data file Checkpoint : 특정 데이터 파일에만 발생하는 체크포인트, tablespace의 offline, hotbackup 수행 시 발생
  라. Mini Checkpoint : 특정 DDL 발생 시 특정 블록에만 발생
  마. Recover Checkpoint : 데이터파일에 장애발생 시 발생하는 체크포인트

참고 : FAST_START_MTTR_TARGET
8i부터 사용되는 파라미터, 단위는 초, 값이 작을수록 복구시간이 짧아지나 checkpoint가 자주 발생하여 서버의 성능이 저하된다.

* MTTR(Mean Time To Recovery) : 복구평균시간

********************
******************** 
******************** 

Redo log 관련 latch 경합 추가설명

개선