오라클 성능 고도화 원리와 해법 (Ch.1 1~5)

by

01 기본 아키텍쳐

DBA가 아닌 이상 그렇게 중요한 용어 및 개념이 있어보이진 않는다.

중간에 ‘디스크 액세스 암’ 이야기가 나오기도 하고….

학부시절 개론 수준으로 이야기 되는 Multi User One Resource개념을 훑고 넘어가는 정도라서 대개는 생략해도 됨.

하지만 중요한 핵심 키워드 몇개는 존재. 이 부분만 짚고 간다.

  • Latch
  • SGA (System Global Area)

multi user의 특징인, 경합 상태에서의 공유메모리를 무분별하게 건드리는 케이스에서는 읽기/쓰기 일관성이 보장이 안된다.

이 때, SGA라는 공유 메모리 영역의 데이터 엑세스를 보호하기 오라클은 (당연히) 락을 사용하고, 이 락 메커니즘을 ‘Latch’라고 한다.

그리고 SGA에는 뭐 shared pool, Buffer cache, redo log buffer등, 죄다 처음 들어보는 용어들이 가득가득..

이 챕터에서 가장 중요하게 생각할 만한 요소 및 용어는 이것일 듯 하다. (물론 깊게 공부한다면 끝이 없을테지만, 난 DBA가 아니라 서비스 개발자이기에 ‘그렇다더구나’ 정도로만 이해할 생각)

  • 오라클은 multi user 기반의 다중 접속을 지원한다
  • 오라클도 하나의 물리서버가 아니라 여러대의 인스턴스로 서비스를 제공한다 –> RAC(Real Application Cluster) 환경이라고 함
    • 어? 그렇다면, RAC환경에서의 데이터 일관성을 어떻게 보장하고 있는가?
    • 중간데 글로벌 캐시 레이어가 있다. RAC구조의 인스턴스에서 전용망을 통해 데이터 동기화를 이룸

02 DB 버퍼 캐시

SGA라는 공유메모리 내에서도, 우리가 흔히 인지하는 ‘SELECT/DML등을 통해 read/write 한 데이터를 실제 블록에 read/write하는데 있어서 중간에 캐시 역할을 하는 친구를 ‘DB 버퍼 캐시(버퍼캐시)’ 라고들 한다.

이 챕터의 시작에서는, ‘오라클은 블록 단위로 I/O를 한다’ 라는 설명을 하고, 이 ‘블록I/O’ 가 성능에 있어서 매우 중요한 역할을 한다고 몇번이나 강조한다.
하지만 난 이해를 못했다. 디스크 블록일지…. 그냥 가상 개념의 ‘블록’일지 감이 잘 안잡힘. 블록I/O의 개념이 SSD가 나오면서부터 좀 달라지기도 했을거고……..
오라클 튜닝 관점에서야 중요하겠지만 일단 ‘블록I/O기반이다’ 를 외워두고 이후 내용들을 보면 이해가 가겠지…

이 챕터에서 강조하는건, 버퍼캐시의 구조와 ‘어떤 방식으로 버퍼캐시가 캐시데이터를 빠른 시간복잡도로 원하는 데이터에 접근하는지’ 에 대한 설명이 들어가있다.

글로 쓰면 한도끝도 없을 것 같다..

일단 버퍼캐시의 버퍼블록은, 흔히 생각하는 RAM의 random access의 구조를 따르고 있어서, 순차 접근이 불가능하다.

그래서, 해시 버킷이라고 하는 hash맵을 갖고서 이 버퍼캐시의 블록을 ‘어떻게 빠르게 찾느냐’ 에 대한 메타정보를 담고있는 버퍼헤더도 같이 운용한다. 이것이 버퍼캐시 내의 버퍼헤더라고 하고…. 이 헤더를 잘 운용함으로써 작은 시간복잡도로 원하는 데이터에 접근이 가능하다고 한다.

03 버퍼 Lock

이 부분은 사실 이해가 잘 안갔….

무결성을 보장하려면, 버퍼캐시에 접근하는 user가 래치를 점유하고 해제해야 하는데, 그떄 이 버퍼 lock에 대한 설명이 들어가 있음

이떄의 버퍼 lock을 다른말로 ‘버퍼 Pin’이라고 하는데….. 일단 난 처음 들어봄….

버퍼캐시에 값을 쓰기 할 때에는 당연히 1user 1lock이나, 읽기 동작은 여러명의 user가 lock을 획득할 수 있다고 하는 이야기도 나오고….. 해당 챕터에서는 그냥 크게 중요한 키워드나 개념/메커니즘은 나오지 않은 듯 하여, 그냥 슥슥 읽고 넘어감

04 Redo

오라클은, 기본적으로 버퍼 캐시도 두고, 실 DML처리를 디스크에 쓰는것도 버퍼링을 두어 동작하기에, 만에 하나….

  • DML처리가 된 사항들이 최종 디스크에 write되지 않았을 시 데이터 유실

되는 구조로 운영된다.

하지만, DBMS의 신뢰성에 있어서 이건 용납할 수 없기에 Redo라는 스펙이 존재한다.

이 일련의 데이터 write를, Redo로그파일에 로그를 쌓는 방식으로 무결성을 보장하고 있으며, 당연히 로그 데이터는 한정적이기에 라운드 로빈 방식으로 이 redo를 관리한다.

  1. DB recovery
  2. Cache recovery
  3. Fast Commit

이 세가지의 기능을 지원하기 위해 Redo로그를 사용한다고 한다.

  1. DB recovery, Cache recovery
    • 당연히 그래서는 안되겠지만, DB fail시에 (전원이 나갔다던가..) 이전에 작업하고 미처 실 데이터에 최종 write 가 되지 않은 영역을 리커버리 하기 위함
  2. Fast Commit
    • 앞선 DB recovery, cache recovery랑 일맥상통하는 개념인데… ‘실 데이터에 최종 write가 될 때까지’ 커밋 완료 여부를 기다리기엔 엄~~~~~~~청난 성능 저하가 오기에, redo 로그를 통해서 커밋을 최대한 빨리 종료할 수 있게 기능을 지원해 준다.ㅎㅎ

p.s : 밑에서 이야기 할 Undo와 함께 꽤 중요한 개념…. 사실 DB fail 이후 복구할때 Redo만으로는 완전 복구가 안된다. Undo도 같이 있어야 함..

05 Undo

‘롤백’이라는 용어와 동일하게 생각하면 된다. (실제로 DML잘못때리고 콘솔에 ROLLBACK; 명령어 칠때, 이 Undo세그먼트를 보고 롤백함.)

거두절미하고… 그냥 본론부터…

  1. 트랜잭션 롤백
  2. 트랜잭션 리커버리
  3. 읽기 일관성

첫째,

일단 트랜잭션 롤백/DB fail이후 복구시에 우선 Redo를 통해 리커버리를 하면, 문제가 생긴다.

  • 최종적으로 커밋 안찍은 애들까지 복구됨

……. 고럴떄 이제 커밋되지 않은 내용들을 롤백하는데, 이때 이 Undo를 사용한다.

둘째,

Undo데이터는 읽기 일관성을 위해 사용하는데, ‘내가 읽은 시점에 다른 user가 이미 DML을 쳐 버린 상황’ 등에서 이 Undo를 매우 요긴하게 사용한다.

내가 생각했을떈 이 Undo를 통한 읽기 일관성 덕분에, 오라클이 ‘성능이 좋다’ 라는 취급을 받는거 아닌가 싶다.

  • 타 DB들은 그냥 읽을때에도 다른 user가 write를 못하게 lock을 검….

어차피 다음 챕터에서 오라클이 읽기 일관성을 어떻게 유지하는지 잘 설명이 된다. 이 부분은 정독하자…ㅋㅋ

그리고 트랜잭션 테이블 슬롯이란 구조를 통하여, 이 Undo세그먼트를 관리한다는 설명들도 너줄너줄 있긴 한데….이해를 잘 못했다… DBA 관점으로 깊게 알아두고 싶을떄 읽어야겠다…..

Leave a Comment