Step 2. LGWR(Log Witer)
블로그를 써야지 써야지 하다가 또 한참 지나고 쓰네요..ㅎ
Log Writer. 즉 LGWR은 Redo Log File과 Redo Log Buffer와 연관성이 깊습니다.
DBWR처럼 LGWR도 Buffer에 있는 것을 File에다가 전송을 하게 됩니다.
Buffer는 메모리이고 휘발성이며 File은 스토리지이고 비휘발성이기 때문이죠 ㅎ
LGWR이 동작할 때는
- Commit이 발생했을때
- 1/3이 찼을때
- 변경량이 1M가 됐을 때
- 3초 마다
- DBWR이 내려쓰기전에
- 로그스위치가 일어날 때
LGWR의 특징으로는 몇가지가 있는데 살펴보도록 하겠습니다
- 선로그기법(Log Ahead Method or Write-Ahead)
선로그 기법은 쿼리(update, delete, insert)를 날리면 먼저 Redo Log Buffer에 쌓인다는 것입니다. 이 이유는 DBWR이 Database Buffer Cahe에 있는 것을 Data File에 전송시키 위한 조건중에는 commit이 없습니다. 테이블 변경이나 임계값이 지나거나 등등의 이유가 많죠. 그렇기 때문에 선로그 기법을 통하여 Redo Log Buffer에 먼저 쌓고 DB Buffer Cache에 데이터를 저장하는 형식이 됩니다.
이렇게 하는 또하나의 이유는 블록사이즈입니다. DB Buffer Cache의 사이즈는 default 8k입니다. I/O를 많이 잡아먹는다는 거죠. 그만큼 무겁도 많다는 것이기도 하구요. 하지만 Log Buffer의 경우에는 default가 512 byte입니다. 무려 16배의 차이가 납니다. 그래서 비교적 I/O의 손실을 줄이기 위해 수시로 왔다갔다 했을때 부담이 없는 Log Buffer에 먼저 저장을 하게 됩니다. 또한 commit을 할때에도 Redo Log File에 쓰기가 부담이 덜하죠. 속도도 더 빠를거구요. 이 속도에 관해서는 하나 더 말하자면 data의 경우 해당 위치의 data를 불러온 후 메모리에 적재하고 내용수정이 된것을 메모리에 적재된 것에 대해 변경시킨 후 다시 해당 data block의 위치에 넣어야 합니다. 그렇기 때문에 위치찾는 시간 또한 무시를 못하겠죠?ㅎ 대신 log buffer와 file의 경우 시간단위로 그냥 쭉쭉쭉 내려 쓰기때문에 간편하고 위치 찾는 시간이 걸리지가 않습니다.
database buffer와 파일에 대해서 한번더 설명을 드릴게요 그림으로 ㅎ
뭔가 최면거는거 같긴한데..ㅎ 지금 여러분이 이 도서관에 있다고 생각해보죠 ㅎ
물론 정해진 분류와 인덱스에 따라 책들이 존재하겠죠. 이중에 한 책을 제가 수정을 하고 싶습니다.
그러면 그 책을 우선 찾아야겠죠?ㅎ 일정한 규칙이 있다고 해도 찾아야 합니다. 책을 조금의 시간이 걸려서 찾았습니다.
찾아서 앉아서 책 한줄을 쓰려합니다. 책에 쓰면 다시 지우기 힘드니까 메모지에 내용을 미리 적어 놓구요.
메모지에 넣은 내용을 그대로 책에도 쓰고 또 고칠것이 없다고 판단이 됐을때 책을 덮고 다시 원래 위치를 찾아서 놔야겠죠 ㅎ
이렇듯 메모지를 log buffer, 책을 data file이라고 봤을때 data file을 찾고 쓰고 다시 집어넣고 하는 귀찮은 작업을 하는데 메모지는 그냥 미리 적어넣은 것을 둘뿐이죠. 그냥 시간순으로 쭉쭉쭉 나열을 해놓은 것이구요. 나중에 이걸 문서로 저장하려면 위치찾고 그럴 필요없이 메모지를 뙇하고 붙이면 끝이겠죠?ㅎ 저만 그렇게 생각하나요 ㅎ
복구관점에서 보더라도 데이터를 실질적으로 저장하기전에 로그가 있어야 복구를 하기에도 수월하겠죠 ㅎ
책에다가 뭘 썼었는지는 redo log buffer가 있으니까요 ㅎ 그리고 원본을 가지고 있는 undo도 있구요 ㅎ 물론 commit하기 전잊지만요
- 동시커밋
커밋을 여러사람이 동시에 했을경우에는 어떻게 하게 될까요?? Group Commit을 써서 간단하게 동작을 하게 됩니다.
예를 들어서 다섯명의 사람이 동시에 같은 시점에 commit을 하게 된다면?
이럴경우의 이점은 I/O가 5번이 일어나야하지만 똑똑한 오라클은 Group commit의 방식으로 한번의 i/o로 다섯개의 log를 저장하게 합니다 ㅎ
- 빠른커밋
어느정도 다 예상은 하셨을 것이라 생각은 하지만..ㅎ 앞에서 살짝 언급했던 것이 있습니다. DBWR은 데이터를 모았다가 일정시점이 되면 Buffer에 있는 것을 Data File에 저장을 합니다. 그러면 제가 insert나 update를 한다고 해서 data file에 있는 것이 아니고 메모리에 있는 상황이 되는 것이겠죠 ㅎ 실질적으로 저희가 보는 것은 지연쓰기(Deferred Write)를 한 상태의 데이터를 보는 것이고 메모리에 있는 것을 보는 건데 이 데이터는 redo log쪽에서도 볼수 있다는 겁니다.
즉, data file에는 없어도 redo log file에는 존재 할 수 있다는 것!이죠 ㅎ
- 관련 파라미터
redo log buffer에 대한 사이즈
show parameter log_buffer;
db buffer cache의 경우 block size를 갖지만 redo log의 경우 os의 block 단위를 봐야합니다.
select max(lebsz) from sys.x$kccle;
히든파라미터로 되어 있죠 ㅎ
이상 LGWR이었습니다. Redo log file과 undo, arch 모드는 따로 또 설명하도록 하겠습니당 ㅎ
다음은 PMON이 되겠네요 ㅎ
'Oracle > Oracle Admin' 카테고리의 다른 글
Database Oracle Administrator_Oracle Background Process_DBWR (0) | 2015.04.12 |
---|---|
Database Oracle Administrator_SQL 문장의 실행 원리 (0) | 2015.03.29 |
Database Oracle Administrator_PGA의 구성요소 (0) | 2015.03.29 |
Database Oracle Administrator_Dynamic SGA 기능 (0) | 2015.03.29 |
Database Oracle Administrator_SGA의 주요구성요소(Shared Pool 및 기타 요소) (0) | 2015.03.29 |