Database Oracle Administrator_Oracle Background Process_DBWR

Step 1. DBWR(Database Writer)

 

우선 DBWR로 들어가기전에 프로세스들이 무엇이 있는지부터 말해볼게요 ㅎ

Oracle Server의 Process들은 크게 User Process, Server Process, Background process 세가지가 있습니다.

 

- User Process

 Client인 User들이 가지고 있는 Process를 User Process라고 합니다. 여기서 SQL을 Server Process에 전달

 

- Server Process

 User Process가 전달한 SQL 질의문을 실제적으로 실행하는 것이 바로 서버 프로세스!

 

- Background Process

 지금 다루려고 하는 뒷단에서 보조적인 역할을 하며 운영과 유지를 도와주는 프로세스

 

 

본격적으로 Background Process 들에 대해서 설명을 해볼게요 ㅎ

먼저 DBWR은 무엇인가!?

 

DBWR은 풀네임처럼 간단하게 Database에 데이터를 쓰는 겁니다.

너무 간단한가요?ㅎㅎ 이전에 말한 것 처럼 데이터베이스는 처리한 것들을 메모리에 쓰게 됩니다.

메모리의 용량은 커널에 의해서 정해져 있고 database의 parameter file(pfile, spfile)에 의해 결정이 된채로 서버가 오픈됩니다

무한한 용량이 아니라는 거죠 ㅎ 데이터베이스도 하나의 소프트웨어에 불과하기 때문입니다.

 

우리가 DB에서 하는 모든 행위들이 메모리에 저장이 되고 메모리에 저장이 된것을 영구적으로 보관하기 위해서 Storage(저장매체)에 이관을 시켜야 합니다. 메모리는 끄면 사라지는 휘발성이라 그렇습니다 ㅎ

 

위에서 말하는 스토리지는 Data File입니다. Database Buffer Cache에 쌓인 것들을 가지고 각 테이블스페이스에 할당된 데이터파일에 데이터를 이관시키는 거죠 ㅎ

 

좀 더 쉽게 설명을 하자면 제가 메모를 해놓지 않으면 다음날 까먹는 사람입니다.

그래서 기억하는 것을 적어 놓지 않은 채로 다음날이 되면 전날 생각한 것을 까먹고 기억을 못한채로 살아가는거죠..

급 비극이 되어 버렸네요..ㅋㅋㅋ 극단적인 예니까요 ㅎ 이렇듯 기록을 해놓지 않으면 뇌의 기억력 한계라는 게 있고 적어 놓지 않으면 까먹게 됩니다. 천재라면 그렇지 않을수도 !?ㅎ

 

그린 하나를 간단히 보도록 하죠 ㅎ

 

 

 

 

 

 

지금 이 그림으로 간단히 설명을 드리면 제가 cgv에서 어벤저스 : 에이지 오브 울트론을 예매하는 사진 > <이에요 ㅎㅎ

저건 영등포 스타리움관인데 벌써 저렇게 찬거..ㅎ 전 오전에 다른 예매를 이미 완료했습니다! IMAX 뜨면 바로 옮길거에요 ㅋ

 

중요한건 이게 아니라 극장 몌매를 보면 이미 예매완료가 된 것들(연회색)과 예매하려고 하는 좌석(빨간색)과 예매가 가능한 좌석(진회색)이 있죠 ㅎ 예매를 끝내지 않고 그냥 닫아버리면 빨간색은 다시 진회색이 되고 예매가 가능한 공간이 되어 버립니다. 이러한 예는 오히려 Transaction에 맞는 예긴 하지만..ㅎ 이렇듯 저장을 하지 않으면 날라간다는거 !?ㅎ

 

그리고 좀 더 적합한 예로 수술실을 들겠습니다 ㅎ

 

 

이전에 Databaes Buffer Cache를 설명 했을때에도 했던 수술실인데요 ㅎ

 

다시한번 설명을 하자면 수술실에는 환자가 없이 수술이 가능한 상태, 수술중인 상태, 수술이 끝난 상태가 있습니다.

이를 각각 Free, Pinned, Dirty 라고 합니다.

 

수술이 가능한 곳(Free)에서 환자를 받아서 수술을 하고(Pinned) 수술이 끝난 후 정리하는 시간(Dirty)이라고 보면 쉽습니다.

수술중일 때는 침범하지 못하고 수술이 끝나도 지저분하면 환자를 수술할 수 없으니까 Free인 곳은 찾는 거죠 ㅎ

 

- Pinned Buffer : 다른 사용자가 현재 사용하고 있는 Buffer 블록을 의미. Pinned 상태의 경우 다른 사용자가 사용 불가능!

 

- Dirty Buffer : 현재 작업은 진행되지 않지만 다른 사용자가 내용을 변경한 후 데이터 파일에 변경된 내용을 저장하지 않은 Buffer. 이상태의 경우 아직 저장하지 않았으므로 다른 사용자가 사용불가능합니다.

 

- Free Buffer : 이름에서부터 촉이 오죠?ㅎ 애초에 사용되지 않았거나 Dirty 상태에서 저장을 완료하여 Free가 된 상태의 Buffer입니다. 다른 사용자가 사용가능하단 뜻!

 

그러면 Database Buffrer Cache는 언제 Data File로 이관이 될까요?

 

1. Checkpoint 신호가 발생했을 때

2. Dirty Buffer 임계값이 지났을 때

3. Time out이 발생했을 때

4. RAC Ping이 발생했을 때

5. Tablespace가 Read Only 상태로 변경될 때

6. Tablespace가 offline이 될 때

7. Tablespace가 begin backup 상태가 될 때

8. Drop table이나 Truncate Table 될 때

9. Direct Path Read/Write가 진행 될 때

10. 일부 Parallel Query 작업이 진행될 때

 

10가지가 있습니다. 무작정 외우면 힘들겠죠..ㅎ

 

Checkpoint는 간단히 말하면 Data File과 Database Buffer Cache의 데이터를 일치시키는 역할로 헤더에 정보를 기입시킵니다. 자세한건 뒤에서 또 다루도록 하죠 ㅎ

 

DBWR과 CKPT, LGWR은 긴밀한 관계가 형성이 되어 있기때문에 잘 알아두어야 합니다.

 

Dirty Buffer의 임계값이 지나면 이라는 조건은 Dirty Buffer가 많아진다는 것은 완료된 작업은 많은데 Data File에 저장이 되지 않았으므로 Free Buffer가 되지 않고 제한적인 Memory에 Free가 없다는 것이죠 ㅎ 그래서 특정 임계값이 지나면 Free로 만들어 주기위해 Dirty Buffer를 Data File로 옮겨줍니다.

 

Timeout은 3초로 되어 있습니다. 즉 3초가 지나면 Data File로 저장을 시킨다는거죠 ㅎ

 

Real Application Cluster에서 Ping을 날리는 것은 해당 서버가 살아 있는지, 네트워크가 연결 되어 있는지 확인하기 위해 Ping을 날리게 되는데 이때 공유 스토리지에 자신이 가지고 있는 정보를 이관시키게 됩니다.

 

Tablespace의 상태변화가 일어나면 특정 Checkpoint가 발생하는데 이 체크포인트를 DataFile Checkpoint라고 부릅니다.

Read only, offline, begin backup 등은 뒤에서 설명을 하게 될거구요 ㅎ 읽기전용, 미사용, 백업 시작이라고 간단히 알아 두시기 바랍니다. 테이블스페이스에 관련된 작업이 일어나기때문에 기존 메모리에 대한 정보가 File로 안전하게 이관이 되어야 겠죠 ㅎ 안그럼 불완전 작업이 되니까요.

 

Drop table이나 Truncate Table도 마찬가지로 해당 테이블에 대한 데이터를 모두 지우는 것이기 때문에 기존 데이터에 대한 기록을 Data File에 넣어야 합니다.

 

Direct Path I/O에 대해서는 상당히 생소한데요.. ㅎ

일반적인 블록 I/O들은 Database Buffer Cache를 경유해서 가야합니다. Buffer Cache를 먼저 찾아보고 못찾으면 Disk(Data File)에서 읽어야 한다는 것인데요. 대용량 데이터를 읽을 경우에는 대용량의 데이터가 없을 경우 File에 있는 것을 Cache로 올려서 봐야한 다는 것이 상당히 서버에 부하를 주는 일이 됩니다. 즉, 일회용성의 데이터일 경우 경유하지 않고 Direct로 가는 것이 성능적으로 더 유리하다고 볼 수 있다는 것이죠 ㅎ

 

이게 Direct Path의 간단한 소개입니다ㅎ 대용량의 경우 오히려 과부하가 걸릴 수 있으므로 직접 데이터 블록을 쓰는 것이죠

Read/Write의 경우에 설명을 하면

- Read는 병렬쿼리로 Full scan을 할 경우 Buffer를 거치지 않고 바로 Data Block으로 찾아가게 됩니다. 이 경우에 Database Buffer Cache에 아직 DBWR이 동작하지 않아서 동기화 되지 않은 데이터가 있다면 문제가 될 수 있으므로 먼저 DBWR이 이를 감지하고 Data File에 이관을 시켜줘서 정합성을 맞춰주는 것입니다.

- Write도 마찬가지로 병렬 DML을 수행하거나 Direct Path Insert할때마다 I/O Call이 발생하는데 이때 데이터를 맞춰줍니다.

 

Direct Path의 대략적인 설명이었구요 ㅎ 나중에 좀 더 자세히 다루도록 하겠습니다 ㅎ

 

병렬 Query를 날릴때 DBWR이 발생하는 것도 다중 처리가 되야하기 때문에 데이터 정합성을 맞추기 위해 조건이 들어간 것입니다.

 

이렇듯 DBWR은 다른 이름으로 DBWn이라는 이름으로 쓰이기도 하는데요. 다중 프로세스로 이용 되기 때문입니다.

DBW0~ DBW9 까지와 DBWa ~ DBWz까지 총 36개의 프로세스가 있습니다 ㅎ

 

현재 동작하는 파라미터가 몇개인지는

 

show parameter process; 를 보면 됩니다.

 

 

여기서 db_writer_processes를 보면 되겠죠 ㅎ 지금 1개가 떠있는 것을 알 수 있습니다.

 

DBWR에 대한 설명은 이것으로 끝! 다음에는 LGWR로 돌아오겠습니다 ㅎ