오라클 기본 구조

 

오라클은 위와 같은 기본 구조를 가지고 있다.
  SGA밑에 있는 초록색 타원은 backgroud process로 필요시에 움직이게 된다.
  그 밑에 있는 분홍색 원통의 것은 물리적인 파일을 의미하는 것으로 datafile을 의미한다.

◇ oracle instance
   DB엑세스 속도향상을 위한 구조이다.
  대용량이든 아니든 데이터베이스의 궁극적인 목표는 데이터의 안정성과 엑세스 속도의 향상이다.
  엑세스 속도의 향상을 위해서  위의 구조를 사용하게 되는데 밑에 있는 원통형 모양의 datafile들은
  물리적인 파일들이다.(오라클을 설치한 곳 어디엔가 분명히 존재하고 있는 파일들이다.) 하지만
  위의 오라클 인스턴스는 메모리상에서 상주하기 때문에 찾아보기 힘들 것이다.
  이해를 돕기 위해서 하드디스크와 램을 생각해보면 된다. 하드디스크->데이터파일, 램->인스턴스
  라고 생각한다면 쉽다. 우리가 쓰는 일반적인 컴퓨터에서도 속도향상을 위해서 하드디스크에 있는
  내용을 램메모리에 상주시켜서 속도향상을 꾀하곤 한다. I/O가 기본 단위가 되는 오라클은 이런
  I/O의 수를 줄이기 위한 여러가지 방법을 사용하고 있다.
 
     -  shared pool

말 그대로 공유를 하기 위한 공간이다. 무엇을 공유하는가? 작성한 sql문의 실행계획,
syntax, parse-tree, compile정보 등을 공유하게 된다. 무슨 말인지 상세히 알아보자.

  1)library cache
    sql문을 실행할때에는 당연히 parsing을 통해 구문을 분석해야만 한다. 그렇다면
    매번 똑같은 문장을 위해서 parsing을 하게된다면 이 역시 낭비일 것이다. 이를 위해
    library cache에서는 이런 정보를 저장하고 다음 sql문을 실행할 때에 library cache에
    같은 내용이 있다면 그 내용을 통해서 실행계획, systax등을 가져와 빠른 실행을
    돕는 것이다.

    * parsing이란 -> 만약
        select * from employees;
      를 수행하게 될 때 컴파일러가 알 수 있도록 구문 분석하는 것을 말하는데
      select, *, from, employees를 각각 떼어내서 어느 부분까지 select문인지
      어느부분까지 from문인지를 분석 하는 과정을 말한다.

  2)Data Dictionary cache
    위의 employees 테이블을 생각해보자. employees table의 정보는 어디에 저장
    되어 있는 것인가?  (employees의 제약조건이나 컴럼명, size등을 의미한다.)
    그것은 Data Dictionary라는 곳에 저장 되어있다. 통칭 employees의 정보들을
    Meta Data라고 정의 한다. 이런 정보들 조차 Data Dictionary에서 가져와야
    employees table을 엑세스 할것인데, 그것은 datafile중에서 system에 저장되어
    또 한번의 I/O를 일으키게 된다. 이것을 막기 위해 Data Dictionary cache에
    이 정보를 저장해둬 엑세스속도를 향상 시키는 것이다.

     - Database buffer cache

select employee_id, last_name, department_id

from employees

where department_id=80;

의 sql문장을 실행하면 department_id가 80번인 정보들을 찾게되는데 여기에서  

80번에 속해져 있는 블록(80번에 속한 정보가 1명이라도 한 블록 전체를)을 엑세스

하게 되는데 이것은 두가지 경우의 수가 나타난다.

첫째로 database buffer cache에 그 블록이 존재하는 경우

  별반 다른 엑세스가 필요없으므로 바로 정보를 읽어버린다.

두번째로 database buffer cache에 그 블록이 없는 경우

  datafile에서 존재하는지 아닌지를 검사하게 되는데 있다면 그것을 database buffer cache로

  올린다음 정보를 읽어버린다. 따라서 성능상 자주 읽는 블록들은 database buffer cache에

  상주시켜 놔야 좋을 것이다. 상주시켜놔야 할 수 있는 %를 parameter로 지정해서 설정해놓을 

  수 있다.

 

database buffer cache는 LRU알고리즘을 사용해서 database buffer cache의 내용을 관리하게 된다.

LRU list를 이용하게 되는데 이것은 database buffer cache의 갯수만큼 존재하게 된다. (블록 단위로

올라감으로 갯수라고 표현했다.) 새로운 data block이 엑세스 되어 database buffer cache에 들어오면

LRU list에서 가장 사용하지 않을 것을 빼내게 된다. 이것을 aging out 이라고 부른다.

     - redo log buffer

commit을 수행하게 되면 데이터가 반 영구적으로 변경되어졌다는 것을 의미한다. database에

접근하고 있는 사용자가 수천명이 될 때, 동시에 500명이 commit을 해서 각각을 datafile에 저장

하게된다면 물리적 I/O가 500번이 되는 샘이다. 이런 부하를 막기 위해서 commit을 하면 바로

datafile에 쓰는 것이 아니라 redo log buffer에 쌓아놓는다. 리두로그 버퍼의 size의 1/3이 차거나

3초가 지나면 redolog file에 쓰게 된다.