1. Redo 기능

Write ahead rule	데이터를 변경(DDL, DML 등) 시키기 전에 반드시 리두를 먼저 생성
Log force at commit	사용자가 커밋을 요청하면 반드시 관련된 데이터를 보장하고 인스턴스 장애 시에 성공적으로 리두 로그 파일로부터 데이터 복구를 함

nologging 기능	대량의 데이터 생성 시 nologging 기능을 사용하면 성능상 큰 개선을 볼 수 있음
참고 URL	http://121.254.172.39:8080/pls/apex/f?p=101:11:0::::P11_QUESTION_ID:4909800346338423

2. LGWR에 의한 Redo 기록

①	매 3초 마다
②	Log Buffer의 1/3 또는 1MB가 저장될 때
③	User Process가 Commit 또는 Rollback으로 Transaction을 종료할 때(Log force at commit)
④	DBWR Process에 의해 신호를 받을 때(write ahead logging)	⑤	Log Force at Commit : Transaction과 관련된 모든 Redo Record를 Log File에 저장 후 Commit 완료)
⑥	Write Ahead Log : Data Buffer에 기록하기 전에 Log Buffer에 먼저 기록		Write Ahead Log : Data File에 기록하기 전에 Log File에 먼저 기록

①	리두 페코드라는 단위로 데이터 변경사항을 저장함
②	리두 버퍼는 리두 레코드를 연속된 형태(SCN 순서)로 저장함
③	리두 버퍼가 꽉 차게 되면 다시 처음부터 레코드를 저장하는 순환구조 사용


SELECT MAX(LEBSZ)
FROM   SYS.XM$KCCLE;

MAX(LEBSZ)                     
----------                     
       512

User Commit 또는 Rollback에 의해 발생함
log file sync Event는 Sync Writes에 의해서만 발생함
☞ log file sync 대기이벤트 : 서버 프로세스가 커밋 명령을 내린 후 LGWR가 성공적으로 기록할 때 까지 기다리게 됨.
이 때 발생하는 이벤트이며, Sync Writes signal을 기다리고 있음을 의미

☞ Sync Writes signal : LGWR 프로세스가 로그 버퍼의 내용을 리두 로그 파일에 기록 완료 한 후에 유저 프로세스에게 전달하는 시그널

☞ log file sync 대기이벤트 원인

Sync Writes를 제외한 나머지 경우에 발생함
대량의 Redo Entries를 발생시키는 Server Process는 Redo Buffer의 공간을 할당 받기 위해 Background Writes를 요청함