Redo Log의 생성원리

Step 1. 사용자가 특정 데이터의 변경을 요청하는 쿼리를 수행하면 해당 SQL을 받은
서버 프로세스는 원하는 Block이 Database Buffer Cache에 있는지 확인한 후 없을 경우 데이터 파일에서
찾아 복사한 후 메모리로 가져온다. 그 후 해당 블록에 Lock을 설정(page fix 라고 함)한 후 PGA에서 redo change vector를 생성한다.
#Change Vector : 변경된 데이터를 나중에 복구를 할 목적으로 Redo Log에 기록할 변경된 데이터에 대한 모든 정보의 세트.(내용 : Undo관련 2가지 + Redo관련 2가지)

Step 2. 서버 프로세스는 PGA에서 Change Vector를 생성한 후 Redo Log Buffer 에서 필요한 용량을 계산. PGA에서 생성된 Change Vector를 Redo Log Buffer에 복사하기 위해 Redo Copy Latch를 획득해야 한다.

Step 3. Redo Copy Latch를 확보한 서버 프로세스는 Redo Log Buffer에 내용을 기록하기 위해 다음 단계인 Redo Allocation Latch를 확보해야 합니다.
8i 이전에는 Redo Alloction Latch가 한개 뿐이어서 경합이 많이 발생하였다. 그래서 9i 들어서 Shared Redo strand 기능이 도입되고 10g이후 부터는 Private Redo strand가 도입되었다.     
#Shared Redo Strand : 하나의 Redo Log Buffer를 마치 디스크의 파티션과 같이 여러 개로 나눔으로써 여러 서버 프로세스가 동시에 작업하게 하여 성능을 높이는 기능.
#Private Redo Strand : Change Vector를 생성한 후 필요한 경우 LGWR이 Redo Log File에 바로 기록.(zero copy redo 라고도 함), shared pool에 private stands 영역을 둬 그 곳에 체인지벡터를 생성후
필요하면 바로 redo log buffer에 기록한다(latch를 얻기위해 경합이 필요없고, pga에서 리두버퍼로 복사가 불필요하다)

Step 4. Redo Log Buffer에 기록된 내용들은 특정상황이 되면 LGWR가 일부를 Redo Log file에 기록하고 Redo Entry(Redo Buffer에 기록된 Chagne Vector)를 Redo Log Buffer에서 삭제(Flush)합니다.
이때에 Redo Writing Latch를 확보한 후에 기록을 하라고 요청합니다.
특정상황
1) 3초마다
2) Redo Log Buffer의 전체 크기의 1/3이 찼거나 1M가 넘을 경우
3) 사용자가 commit or rollback을 수행할 때
4) DBWR 이 LGWR에게 쓰기를 요청할 때