redo log 기록원리 블로그 쓰는 중 .....

1 사용자가 특정 데이터의 변경을 요청하는 쿼리를 수행

2 유저프로세스로 부터 해당 sql을 받은 서버프로세스는 원하는 block가 있는지 없는지 확인

   원하는 파일이 없을 경우 해당 블록을 데이터 파일에서 찾아 복사 후 메모리로 가지고 옴

3 해당 블록의 해당 row부분을 다른 사용자가 바꿀 수 없도록 블록에 lock를 설정 - page fix

4 PGA 영역에서 Server process가 redo change vector 를 생성 후 redo log buffer 에서 필요한 용량을 계산함 

redo change vector : 변경된 데이터를 복구 할 목적으로 redo log에 기록할 변경된 데이터에 대한 모든 정보의 세트

undo 관련 내용도 들어있음 ( rollback 데이터를 복구할 경우

commit 후 checkpoint 발생 전에 DB 강제종료가 일어나서 

DB가 강제 종료 되었을 때도 rollback 해야할 때 이전 데이터가 필요하기 때문) 

changer vector 들은  redo record 라는 형태의 row  단위로 redo log buffer 에 복사 됨

5 Change vector 를 redo log buffer에 복사하기 위해 필요한 redo copy latch를 획득해야 하며, 

   change vector 를 redo buffer 에 복사하는 작업의 전 과정동안 redo copy를 보유해야 함. 

latch : 일종의 번호표 개념, 한정된 메모리 자원을 여러 사용하자 사용할 때 순서를 정리해 주는 역할

    여러개의 Server process가 동시에 데이터를 변경하면, 

    Redo copy latch를 획득하는 과정에서 경합( latch : redo copy 이벤트 대기 ) 이 발생됨

    경합이 발생하면 성능이 저하됨

6 Redo copy latch 를 확보한 Server process는 Redo log buffer에 내용을 기록하기 위해 Redo allocation latch를 확보 해야 함

oracle 8i : Redo allocation latch 1개, 많은 경합이 생겨 성능이 저하됨

oracle 9i : Shared Redo Strand 기능 - Redo log buffer를 여러 개의 공간으로 나누어 각 공간 별로 Redo allocation latch를 할당

               여러 서버 프로세스가 동시에 작업이 가능해 성능이 높아짐 

   Redo log buffer 를 몇 개로 나누는 가가 성능에 영향을 미침 

   Strands : 여러 개로 분할된 영역을 의미

   기본값 LOG_PARALLELISM = 1

  

oracle 10g : LOG_PARALLELISM 가 히든파라미터 _LOG_PARALLELISM 로 바뀜 

oracle 이 동적으로 관리하도록 _LOG_PARALLELISM_DYNAMIC 파라미터가 추가됨

이 값을 TRUE로 설정하면 Oracle 이 해당 Strand 개수를 자동으로 제어함, 권장값은 ( CPU개수 / 8)

Private Redo Strand 기능 - 9i 의 Shared Redo Strand 보다 확장된 개념이 도입됨

        각 Server process 는 Shared pool 에 자신 만의 독립적인 Private Strand 공간을 만들어  

        이 곳에 Change vector 을 생성 후 필요할 경우 LGWR 이 Redo log file 에 바로 기록함

        latch를 거치지 않기 때문에 성능이 향상됨, 그래서 'zero copy redo' 라고도 함 

 7 Redo log buffer에 기록 된 내용( Change