오라클은 기본적으로 fast commit을 지원합니다. 트랜잭션이
발생하게 되면 fast commit을 통해서 데이터파일에 즉각 반영하는
것이 아니라, online redo log에 먼저 redo log buffer의
반영을 합니다.
log switch나 checkpoint가 일어났을 때 또는 DBWR프로세스가
데이터파일에 쓰야만 하는 때(free buffer 부족등) 데이터파일에
메모리에 있는 내용을 기록하게 됩니다. 물론 commit을 안했다고
해서 데이터파일에 기록을 안한다는 것은 아닙니다. checkpoint가
일어나게 되면 또는 DBWR프로세스가 작동하게 되면 commit을 하지
않은 데이터도 데이터파일에 쓰겠죠. 이 두가지에 차이에 대해서는 아래에
설명을 해봅니다.
commit을 하게 되면 LGWR 프로세스가 online redo log file에
redo log buffer에 있는 redo log entry를 write를 하게 됩니다.
이 write작업이 끝나야 commit 이후 프롬프트가 떨어집니다.
즉 commit의 프롬프트가 떨어지지 않았는데 redo log에 기록을하지
않았다는 것은 있을 수가 없지요.
그렇다면.. 트랜잭션이 많다면 어떻게 될까요? 이 때에는
commit이 일어나서 write를 하기 전에 LGWR프로세스가 다른 경우에
의해서 online redo log에 redo log buffer를 write를 한 것입니다.
그러므로 commit이라고 명령을 하는 것이 오래 걸리지 않습니다.
A->B로 변경후 commit을 하였다고 한다면..
LGWR프로세스가 online redo log에는 redo log buffer에 있는
변경정보를 redo log file에 write를 하였으나 DBWR프로세스가
데이터파일에는 write를 하지 않을 수 있습니다. 그러므로 A->B로 변경은
하였으나 데이터파일에는 A라는 값이 그대로 있을 수 있겠죠.
이 때에 DB를 abort로 내리고 DB를 재기동하면 smon 프로세스는
recovery를 수행합니다. 이 때에 online redo log에서 commit되었으나
데이터파일에 반영되지 않은 데이터를 메모리에 올려서 반영하는 작업을
하게 됩니다. 이것을 rollforward라고 합니다.
한편으로 update를 C->D로 변경을 하였다면.. C라는 데이터를 데이터파일에서
읽어와서 rollback image에 C라는 값을 두고, 원본이미지를 D로 변경합니다.
만약 트랜잭션이 많아서 free buffer가 부족하거나 checkpoint가 일어나거나
하게 되면 DBWR프로세스가 데이터파일에 쓰겠죠. 그런데.. 이 때에
C라는 기존 원본은 undo tablespace로 데이터가 들어가고, D라는 변경된
값은 데이터파일에 write를 하게 됩니다.
즉 commit을 하지 않은 데이터가 있으나 DBWR프로세스가 메모리에 있는
데이터를 데이터파일에 저장할 수 있습니다.
이 때에 DB를 abort로 내리고 다시 올리면 smon프로세스는 앞에서 말씀드린
rollforward를 하기도 하지만, rollback도 하게 됩니다. 이 때에는 commit되지
undo에서 commit되지 않은 데이터를 메모리로 올리고, 데이터파일에
undo데이터를 데이터파일에 write를 하게 됩니다. 이것이 바로 rollback입니다.
undo에는 원본이미지, 데이터파일에는 변경이미지가 있으나 commit을 하지
않았으니 undo에 있는 원본이미지를 데이터파일에 변경이미지에 엎어씌워야
겠지요..
발생하게 되면 fast commit을 통해서 데이터파일에 즉각 반영하는
것이 아니라, online redo log에 먼저 redo log buffer의
반영을 합니다.
log switch나 checkpoint가 일어났을 때 또는 DBWR프로세스가
데이터파일에 쓰야만 하는 때(free buffer 부족등) 데이터파일에
메모리에 있는 내용을 기록하게 됩니다. 물론 commit을 안했다고
해서 데이터파일에 기록을 안한다는 것은 아닙니다. checkpoint가
일어나게 되면 또는 DBWR프로세스가 작동하게 되면 commit을 하지
않은 데이터도 데이터파일에 쓰겠죠. 이 두가지에 차이에 대해서는 아래에
설명을 해봅니다.
commit을 하게 되면 LGWR 프로세스가 online redo log file에
redo log buffer에 있는 redo log entry를 write를 하게 됩니다.
이 write작업이 끝나야 commit 이후 프롬프트가 떨어집니다.
즉 commit의 프롬프트가 떨어지지 않았는데 redo log에 기록을하지
않았다는 것은 있을 수가 없지요.
그렇다면.. 트랜잭션이 많다면 어떻게 될까요? 이 때에는
commit이 일어나서 write를 하기 전에 LGWR프로세스가 다른 경우에
의해서 online redo log에 redo log buffer를 write를 한 것입니다.
그러므로 commit이라고 명령을 하는 것이 오래 걸리지 않습니다.
A->B로 변경후 commit을 하였다고 한다면..
LGWR프로세스가 online redo log에는 redo log buffer에 있는
변경정보를 redo log file에 write를 하였으나 DBWR프로세스가
데이터파일에는 write를 하지 않을 수 있습니다. 그러므로 A->B로 변경은
하였으나 데이터파일에는 A라는 값이 그대로 있을 수 있겠죠.
이 때에 DB를 abort로 내리고 DB를 재기동하면 smon 프로세스는
recovery를 수행합니다. 이 때에 online redo log에서 commit되었으나
데이터파일에 반영되지 않은 데이터를 메모리에 올려서 반영하는 작업을
하게 됩니다. 이것을 rollforward라고 합니다.
한편으로 update를 C->D로 변경을 하였다면.. C라는 데이터를 데이터파일에서
읽어와서 rollback image에 C라는 값을 두고, 원본이미지를 D로 변경합니다.
만약 트랜잭션이 많아서 free buffer가 부족하거나 checkpoint가 일어나거나
하게 되면 DBWR프로세스가 데이터파일에 쓰겠죠. 그런데.. 이 때에
C라는 기존 원본은 undo tablespace로 데이터가 들어가고, D라는 변경된
값은 데이터파일에 write를 하게 됩니다.
즉 commit을 하지 않은 데이터가 있으나 DBWR프로세스가 메모리에 있는
데이터를 데이터파일에 저장할 수 있습니다.
이 때에 DB를 abort로 내리고 다시 올리면 smon프로세스는 앞에서 말씀드린
rollforward를 하기도 하지만, rollback도 하게 됩니다. 이 때에는 commit되지
undo에서 commit되지 않은 데이터를 메모리로 올리고, 데이터파일에
undo데이터를 데이터파일에 write를 하게 됩니다. 이것이 바로 rollback입니다.
undo에는 원본이미지, 데이터파일에는 변경이미지가 있으나 commit을 하지
않았으니 undo에 있는 원본이미지를 데이터파일에 변경이미지에 엎어씌워야
겠지요..
댓글 없음:
댓글 쓰기