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에 먼저 기록
2) 모든 프로세서는 리두 버퍼에 변경사항을 저장함
①
리두 페코드라는 단위로 데이터 변경사항을 저장함
②
리두 버퍼는 리두 레코드를 연속된 형태(SCN 순서)로 저장함
③
리두 버퍼가 꽉 차게 되면 다시 처음부터 레코드를 저장하는 순환구조 사용
3) 참고사항
LGWR가 리두 버퍼 내용을 리두 버퍼 로그에 기록하는 것을 백그라운드 기록이라 함
백그라운드 기록의 기준이 되는 크기는 _LOG_IO_SIZE이며, 10g 기준 리두버퍼의 1/6임(9i는 1/3)
리두 로그 파일은 리두 로그 블록 단위로 기록됨
SELECT MAX(LEBSZ)
FROM SYS.XM$KCCLE;
MAX(LEBSZ)
----------
512
오라클의 커밋은 커밋 순간의 SCN 까지는 복구를 보장하겠다는 의미
3. Sync Writes / Background Writes
1) Sync Writes
User Commit 또는 Rollback에 의해 발생함
log file sync Event는 Sync Writes에 의해서만 발생함
☞ log file sync 대기이벤트 : 서버 프로세스가 커밋 명령을 내린 후 LGWR가 성공적으로 기록할 때 까지 기다리게 됨.
이 때 발생하는 이벤트이며, Sync Writes signal을 기다리고 있음을 의미
☞ Sync Writes signal : LGWR 프로세스가 로그 버퍼의 내용을 리두 로그 파일에 기록 완료 한 후에 유저 프로세스에게 전달하는 시그널
☞ log file sync 대기이벤트 원인
①
잦은 커밋
②
I/O 시스템 성능이 느린 경우
③
많은 리두의 양
④
리두 버퍼의 크기
2) Background Writes
Sync Writes를 제외한 나머지 경우에 발생함
대량의 Redo Entries를 발생시키는 Server Process는 Redo Buffer의 공간을 할당 받기 위해 Background Writes를 요청함
Comments (2)
10월 19, 2010
장태길 says:
완전 기대 만빵 ㅎㅎ완전 기대 만빵 ㅎㅎ
10월 19, 2010
강정식 says:
왜그러세여.. 부담스럽게 ㅡㅡ; 토욜날 형한테 많이 물어볼께여..왜그러세여.. 부담스럽게 ㅡㅡ;
토욜날 형한테 많이 물어볼께여..