Oracle 내부구조
Database는 전형적인 Server / Client 구조이다. Server 가 주체가 되어야지 Client 가 주체가 되어서는 절대 안된다. 20만건에 대해서 처리할 일이 있을 때 우리가 20만건의 DBMS Call을 하면서 Database Server는 그냥 시킨 단순한 잡무만 하게 해서는 절대 좋은 성능이 나올수가 없다. 1번의 DBMS Call로 Server 가 20만건을 모두 처리한 후 우리에게 결과를 알려주는 식으로 해야한다.
오라클의 메모리는 크게 2가지로 나눌수가 있다.
- PGA (Program Global Area) : Process 혹은 Thread의 개별적인 메모리 공간으로 사용자마다 개별적으로 사용하는 공간
- SGA (System Global Area) : 오라클 프로세스들이 접근하는 큰 공유 메모리 세그먼트
(Shared Pool, D/B Buffer Cache, Redo Log Buffer, Java Pool, Large Pool)
사용자가 Database에 직접 접속을 하면 그 접속을 이루기 위해서 많은 자원이 할당받아야하며 그 시간이 무척 오래 걸린다. 그래서 보통 3Tier로 간다. 사용자가 Linsener에게 접속을 하면 사용자가 현재 Database와 통신이 가능한 Dispatcher 중 유효한 것을 찾아서 사용자와 연결시켜 준다. Dispatcher는 미리 Database와는 연결이 된 상태이므로 접속을 위한 자원할당 및 시간은 여기서 소모되지 않는다.
통상적으로는 Multi-Threaded Server 가 더 유연하지만 몇몇 Batch 작업의 경우에는 Dedicated Server 환경이 휠씬 더 효율적이다. Oracle은 이 2가지 접속 형태를 모두 지원한다.
Database Buffer 에는 우리가 읽는 Data Block 들이 임시로 저장되는 곳이다.
Shared SQL Pool은 우리가 실행시키는 SQL문이 임시로 저장되는 곳이다.
보통 Programming 할 경우
String sSql1 = "SELECT * FROM Tbl WHERE ID = '1234';"
String sSql2 = "SELECT * FROM Tbl WHERE ID = '1235';"
이렇게 SQL문을 만들어서 실행을 시키는 경우가 많다. 이럴 경우 위의 2 SQL문은 다른 SQL문이 되어서 Shared SQL Pool에 따로 공간을 차지하게 된다. 이런것을 Dynamic SQL이라 부르는데, 이것을 Static SQL로 고치면 Shared SQL Pool의 같은 공간에 저장된 SQL문을 사용함으로써 성능 향상에 도움이 된다.
String sSql = "SELECT * FROM Tbl WHERE ID = :v" 와 같은 방법으로 해서 :v 쪽에 값을 Binding 하는 식으로 고쳐야 한다.
그림 아래쪽을 보면 Database Writer (DBWR)이 보일 것이다.
우리가 Transaction을 걸고 DELETE FROM Table1 해서 20만건을 지우고 Commit을 하지 않은 상태라면 그 20만건은 Disk에서 지워져 있을까 아니면 안지워진 상태일까 ? 이건 한번만 해보면 알 수 있다. DELETE를 실행하면 시간이 오래 걸리고, Commit을 실행하면 바로 완료된다. 즉, Commit를 하지 않더라도 이미 Disk에는 지워진 상태이다. 만약 Commit을 하지 않고 DB 기계를 끈 뒤에 다시 키면 DB가 가동되기까지 평소보다 더 긴 시간이 걸린다. 그 이유는 Commit 하지 않은 상태에 대해서 Disk에 Rollback 작업을 수행 후 가동되기 때문이다. 그리고 Disk에는 지워졌지만 아직 다른 곳에서는 참조하기 위해서 해당 값이 필요한 경우 참조하는 곳을 Dirty Block 이라고 한다.
PMON : PGA 들을 관리한다.
SMON : DBMS의 CEO 이다. 모든 작업을 총관리한다.
CKPT : DBWR, LGWR의 실행을 명령하는 역할
Recoverer Process (RECO) : 분산시스템에서 사용되는 Process이다.
은행의 경우를 예를 들어보자. 부산에 있는 은행에서 10만원을 빼서 서울에 있는 은행으로 이채했다고 했을 때, 하나의 Trasaction에 부산은행에서 -10만원, 서울은행에서 +10만원 을 한 후에 Commit을 해야 한다. 부산은행 DB 와 서울은행 DB 가 서로 물리적으로 다른 Server 일 확률이 높다. 이럴 경우 Two-phase Commit 이 일어나야 한다. 먼저 Prepare-phase 을 실행시켜서 양쪽 DB에 모두 Commit할 준비가 되었는지 확인한 후 Commit-phase 로 양쪽 다 Commit을 시킨다. 그런데 만약에 부산은행 DB에는 Commit 되었는데, 서울은행 DB에 Commit이 되지 않았을 경우 RECO 가 동작하면서 계속해서 서울은행 DB Commit을 시도한다. 주기적으로 Check하면서 시도하다가 일정시간안에 성공하지 못하면 부산은행 DB까지 Rollback 시킨다.
* Oracle Parallel Server (OPS)
1개의 물리적 D/B 상에 여러개의 System을 사용하는 것을 말한다. 다른 시스템은 각각 다른 SGA를 가지게 되는데 만약 하나의 시스템이 정상적으로 동작하지 않을 경우 다른 시스템에서 그 역할을 대신 해줄수도 있다. 이 역할을 해주는 것을 Parellel Cache Management (PCM) 이라고 부른다. 하지만 이런 기능은 OS에서 지원이 되어야만 가능하다. HP, Sun 등의 OS 에서의 Distributed Cache Management (DCM)이 지원되어야만 가능하다.
댓글 없음:
댓글 쓰기