Database Oracle Administration_SGA의 주요구성요소(Database Buffer Cache)

Step 1. Oracle Server 전체 구조 살펴보기

- Sub : SGA의 주요구성요소(Database Buffer Cache)

 

저번에는 커널 파라미터와 세마포어까지 살펴보면서 메모리 관리를 어떻게 할 것인지에 대해서 말했습니다.

이제부터는 SGA(System Global Area)에 대해서 좀더 다가가서 알아보겠습니다.

SGA는 파라미터 파일과 다른 각종 사항을 참고해서 생성이 됩니다. 그리고 SGA에서 Oracle 대부분의 작업이 일어납니다.

아주아주 중요하죠?ㅎ 그렇기 때문에 이것을 잘알면 성능 측면에서도 아주 좋은 영향을 끼칩니다.

세세하게 SGA의 구성요소에 대해서 접근해보겠습니다.

 

첫번째로 SGA의 중요한 부분중 하나인 Database Buffer Cache를 알아보겠습니다.

어떠한 역할을 하는지 전에 말하긴 했지만 자세히 다룰거니까 집중!. 우선 어떻게 생긴 아이인지 볼까요?

 

 

 

이건 웬 바둑판? 오셀로? 인가 하시는 분들!? 저만그런가요 ㅎ 그럴 수도있다는거~ㅎ

이건 Database Buffer Cache를 표면화 시킨 모습입니다. RAM이라고 보시면 되구요 ㅎ 여기서 데이터의 조회와 변경이 일어납니다.

하드디스크로부터 데이터를 Database Buffer Cache로 가져온다음 조회 및 수정 후 다시 하드디스크로 옮기는것!

그 중간에는 I/O라는 것이 왔다갔다 하구요 ㅎ 이것 어떻게 설명하고 이해하면 좋을까 생각을 해봤습니다.

굿닥터에 꼿혀있는 저인지라.. 수술방으로 예를 들어볼께요 ㅎ

 

 

 

 

수술실은 원래는 비어있는 상태입니다. 하지만 수술을 해야하는 환자가 있으면 병실에서 환자를 픽업해와서 수술실에서 수술을 진행합니다. 그리고 수술이 끝난뒤 지저분한것을 정리한 후 환자를 다시 병실로 돌려 보냅니다. 이러한 시스템은 일반적인 지성인이라면 아시죵?ㅎ

이것에 빗대어 Buffer Cache와 Hard Disk의 관계를 설명해 볼까 합니다 ㅎ 상상의 나래를 펼쳐봅시다.

 

Database Buffer Cache도 또한 Hard Disk에서 수정 및 조회가 필요한 데이터를 가져옵니다. 이제 데이서 수술을 하는거죠 ㅎ

그런데 수술방 하나에 여러명의 환자가 들어올 수 있나요? 없죠.. 그러면 의사가 실수할 가능성이 높아지고 환자를 잃을 경우도 생기죠.

환자가 많은데 수술실이 부족할 경우는? 의사를 늘리고 수술방을 늘리면 되는겁니다. 이런식으로 데이터와 캐시의 관계를 설명할 수 있죠

여기서 원칙이 하나 발생하는 것을 알 수 있습니다. 하나의 수술실에는 한명의 환자가 들어가듯이 Database Buffer Cache의 한칸에도 데이터가 하나만 들어가야 하는 것을요. 두개이상이 들어갈 수도 없지만 만약 들어간다면 오류의 발생으로 망가질 수 있다는 것을요.

 

환자를 수술실로 불러들이기 전에 간호사 또는 의사는 수술실이 비어있는 지를 확인해야겠지요? 데이터도 해당 수술실의 상태를 알아본 후 다른곳을 알아보아야 충돌없이 수술을, 데이터의 수정 및 조회가 가능한 것입니다. 그럼 그 상태를 어찌 볼것인지..

수술실은 모니터에서 어느곳이 수술중인지 아닌지를 판별해주죠? (그렇게 알고있습니다.. 하하..)

데이터들도 이러한 리스트가 있고 판별하는 척도가 있습니다. 총 세개의 척도로 Pinned, Dirty, Free 이렇게 세개의 척도인데요.

 

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

- Dirty Buffer : 현재 작업은 진행되지 않지만 다른 사용자가 내용을 변경한 후 데이터 파일에 변경된 내용을 저장하지 않은 Buffer.

이상태의 경우 아직 저장하지 않았으므로 다른 사용자가 사용불가능합니다.

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

다른 사용자가 사용가능하단 뜻!

 

 

이것도 한번 수술실에 빗대어 다시한번 이해를 해 봅시다. 수술을 하고 있다면 Pinned. 수술을 끝낸뒤 환자를 아직 병실로 돌려보내지 않거나 더러워서 정리중인상태 Dirty, 수술이 끝난뒤 세팅이 끝난 상태 Free. 간단하죠?ㅎ 연상의 방법을 이용한다면 수월하게 생각가능!ㅎ

 

그리고 데이터의 상태를 나타내는 상태 리스트를 부르는 용어가 따로 있습니다. LRU(Least Recently Used) List라는 것이 있습니다.

말이 어렵지만 뜻자체는 최근에 잘 쓰이지 않았던 것들에 대해서 선입선출을 하겠다는 뜻입니다. 왜 이런것 쓰는지부터 말해야 겠네요

RAM은 하드웨어죠?ㅎ 용량 자체가 고정적인것입니다. 하지만 데이터는 무한정으로 늘어날 수 있습니다.

200MB만을 수용할 수 있는데 300MB가 들어온다면? 어떻게 해야할까요. 이전에 있었던 것을 없애야 하는 경우가 생깁니다.

하지만 아무거나 막 없애면 안되겠죠? 그렇기에 최근에 잘 쓰이지 않았던 것들과 완료된것에 관한 리스트를 만들어 관리하는데 이것이 바로 LRU List와 비슷한 또하나의 리스트인 LRUW List를 합쳐서 쓰는데요. 이것을 Working Data Set이라고 합니다.

 

LRU List는 Share Pool에서도 쓰이기 때문에 다시한번 예를 들어 설명을 드리면 편의점을 운영한다고 상상해봅시다 ㅎ

 

 

 

물건하나를 들여왔습니다. 하지만 이미 매대는 꽉차있습니다. 그런데 저기에 아주 옛날에 들어오고 잘 팔리지 않는 것이 있다면?

그것을 빼겠죠 ㅎ 이렇게 잘 팔리지 않고 오래된 물건들의 리스트를 관리하게 되면 새제품을 오래된 물건과 바꿔서 진열해 놓으면 좋겠죠. 이러한 역할이 LRU List입니다. 그럼 LRU List와 LRUW List는 또 무슨 차이인가~ 알아보겠습니다.

 

 

LRU(Least Recently Used) List

- 메인 리스트 : 사용된 Buffer들의 리스트로 Hot/Cold 영역으로 나누어 집니다.

- 보조 리스트 : 미 사용된 Buffer들이나 DBWR에 의해 기록된 Buffer들의 리스트(Free List)

 

 

LRUw List

- 메인 리스트 : 변경 된 Buffer들의 리스트(Dirty List)

- 보조 리스트 : 현재 DBWR에 의해 기록중인 Buffer들의 리스트

 

 

이게 뭔소리냐.. DBWR은 또 뭐냐.. 하실 수 있습니다. 저도 처음에 그랬으니까요 ㅎ

우선 LRU 리스트부터 볼까요 ㅎ Database Buffer Cache로 데이터를 가지고 와야 할 때 보야아 할 것은 Free Buffer인 블럭이 어떤것인지 부터 보아야 데이터를 가져오겠죠? 하지만 Free가 없다면? LRU List의 Cold 영역의 Free List를 봅니다. 그래도 부족할 경우 블록 Scan을 멈추고 DBWR에게 LRUw List의 Dirty List에 포함된 블록의 데이터들을 이미 작업완료 했으면 데이터를 옮기라고 명령합니다. DBWR은 Buffer Cache에 있는 정보를 Data File로 옮기는 역할을 하는 Background Process입니다. 뒤에서 자세히 ㅎ

이렇게 Dirty에서 Free로 변경된 Buffer들은 LRU List 보조 리스트에 추가가 되겠죠?ㅎ

어쨌든 용량이 부족 할 경우에는 DBWR에게 명령을 내려 Free Buffer를 늘려서 작업이 가능하게 도와준다는 것입니다.

 

또한 여기서 생각해 볼 것이 하나가 있습니다. 단일유저의 경우에는 상관이 없지만 Database는 Server로 쓰이죠?ㅎ 그럼 여러 사람이 쓰게 된다는 것입니다. 그런 여러사람이 한가지 Free Block을 가지고 싸울 수 있고 충돌이 생길 수 있다는 것입니다. 이 경우 Latch라는 것을 Oracle에서 이용을 하는데요. 은행의 번호표같은 역할을 해서 순서를 부여합니다. 이때 순서는 보장하지 않습니다.

Latch의 알고리즘 및 개념은 저한테 너무 어렵네요..ㅎ 튜닝쪽에서 이용하는 개념이라 그런가.. 좀 복잡복잡해보여서 어질

꼭 알아야할건 동일한 유한한 자원을 쓰고 충돌을 방지하기 위해서 Latch라는 것을 이용하고 수정을 위해서 Redo Log Buffer를 이용해야하고 Redo Copy Latch를 확보 후 Redo Allocation Latch 확보하고 메모리 Latch까지 확보를 해야한다는 것. 나중에 제가 이해를 하면 다시 풀어서 올리도록 할께요.. Latch와 Lock은 어렵네요 하하;; 이렇게 Database Buffer Cache에 대한 설명은 끗!

다음에는 Redo log Buffer와 그외로 돌아오겠습니다. Redo의 동작은 매우 중요하기 때문에 다음 포스팅에서 간단히 설명 후 추후에 자세히 설명을 하도록 하겠습니다. Undo의 개념과 복구 개념까지 나오는 터라.. 좀 복잡해요 ㅎ 그럼 다음 포스팅에서 ㅎ 내일이겠죠 ㅎ