ch1.Oracle Architecture

ch1. Oracle Architecture.
[녹음1~2]

(1) Oracle Server의 전체구조. 

 oracle server란 ? : 메모리와 디스크에 생성되는 oracle만의 특별한 구조. 

 ① Instance(메모리) : 작업을 하는 공간.

  - SGA(system global area) : 실제 작업들이 수행되는 공간.

  - 백그라운드 프로세스: oracle server가 잘 운영되도록 해주는 역할

 ② Database(디스크) : 저장을 하는 공간 : Data files, control files, redo log files.

 

 

 

 

(2) Oracle Instance의 할당 및 관리.

1) Instance(메모리) 생성과정

① db 종료된 상태에서 관리자가 oracle을 startup.

② server process가 초기화 파라미터(pfile, spfile)에 적힌 설정을 참고해서 kernel에게 요청. (kernel : 모든 하드웨어 관장하며, 자신만의 관리 방식 존재) 

kernel : 모든 하드웨어를 관장한다. (모든 하드웨어를 관장하며, 자신만의 하드웨어를 관리하는 규칙이 존재한다.)   os kernel 파라미터파일 - 리눅스 : /etc/sysctl.conf                                    - 솔라리스 : /etc/system 파일 (system.conf 아니므로 주의!)

③ kernel이 파라미터를 조회해서 그 파일들에 설정되어 있는 내역으로 공유메모리(SGA) 할당해줌. (server process가 요구하는대로 kernel이 모두 할당해 주지는 않는다.)

 - SGA가 만들어진 후에는 OS kernel이 관리를 하고, 요청했던 server process가 종료되어도 SGA(공유메모리)는 종료되지 않으며, Instance가 종료되어야 SGA가 공유메모리에서 사라진다.

 - OS kernel은 RAM의 일부를 oracle에게 할당해준 후에도 해당 메모리 공간을 다른 프로그램이 사용할 수 없도록 꾸준히 관리해준다.

 

2) 세마포어 (Semaphore=깃발) : 어떤 자원의 현재 사용여부를 표현한다. (set/unset) (보통 세트로 묶어 여러개씩 사용한다.)

 - 역할 : RAM은 모든 server process들이 동시에 함께 사용하는 공유 메모리이기 때문에 oracle이 사용하고 있다하더라도 다른 프로그램이 해당 메모리를 사용하려고 시도할 수 있다. (만약 덮어 쓰게 되버리면 kernel panic이나, 윈도의 bluescreen이 일어남.) 이 때 다른 프로그램이 해당 메모리 공간을 사용할 수 없도록 관리하기위해 세마포어를 사용한다.

 - server에서 동작하는 모든 process는 메모리 블록을 사용하기 전에 해당메모리 블록의 세마포어 상태를 먼저 확인한다.

 → 만약 사용중(set)으로 세팅되어 있으면 process는 대기를 하고 있다가, 해당 블록이 release되어 unset 되는 순간 세마포어를 set으로 세팅하고 자원을 사용한다. 또는 unset되어 있는 다른 메모리 블록을 찾는다.

 

▷kernel이 SGA로 사용할 공유메모리를 oracle에 할당하는 3가지 방법

① 공유메모리로 사용할 물리적 메모리가 충분할 경우 하나의 segment에 전체 SGA가 할당될 수 있다.

② 만약 하나의 segment에 다 할당할 수 없다면 연속된 여러 segment로 분산시켜 할당할 수도 있다.

③ 연속적이 아닌 여러 segment에 분산시켜 할당할 수 있다. → 세번째 방법은 SGA에서 작업하는 속도가 아주 늦어진다.

 

(3) SGA의 주요 구성 요소

 

 

 1) Database Buffer Cache : 실제 작업이 일어나는 공간.

 : 사용자가 데이터를 입력하면 데이터는 하드디스크에 저장되지만, 그 저장되어 있는 데이터를 조회하거나 변경하려면 그 데이터가 저장되어있는 데이터파일 블록을 복사한 후 Database buffer chache(메모리)로 가져와서 작업을 수행한다. 왜냐하면!! 메모리에서 작업하는 속도가 디스크에서 작업하는 속도보다 비교가 안될 만큼 빠르며, 메모리에 있는 데이터는 다른 사용자에게 공유가 될 수 있으므로 여러 사람이 작업하는 환경일 경우 전체적인 작업속도가 빨라진다.

 - 사용자가 조회하거나 변경하는 데이터는 반드시 이곳에 있어야만 한다.

 

 * Database buffer cache의 상태.★★★★★

Pinned Buffer [변경중]	다른 사용자가 현재 사용하고 있는 buffer 블록 → 사용불가.  (음식점을 예로 들면, 다른 고객이 먹고 있는 중이다.)
Dirty Buffer [변경완료/저장안됨]	현재 작업은 진행되지 않지만 다른 사용자가 내용을 변경 한 후 아직 저장하지 않은 Buffer 블록. → 사용 불가.  (음식점을 예로 들면, 다른 고객이 먹고 나갔는데 아직 테이블을 치우지 않은 상태.)
Free Buffer [변경완료/저장완료]	사용되지 않았던지(unused), 또는 Dirty Buffer였다가 하드 디스크로 저장이 완료되어 재사용할 수 있는 블록  → 사용 가능.  (음식점을 예로 들면, 다른 고객이 먹고 나간 후 테이블을 깨끗이 다 치운 상태.)

-> Data를 조회(select)하고 있는 것 과는 상관없다.

 

 * LRU List (Least Recently Used)

  : buffer의 상태를 관리하기 위해 buffer cache가 사용가능한 Free buffer와, Dirty buffer들의 목록을 따로 만들어둔 list.

  - LRU 알고리즘을 이용 : 공유메모리는 용량이 제한적이다.  사용자들이 작업하기 원하는 모든 데이터는 SGA로 복사되어야 하는데, SGA용량보다 사용자가 변경하고자 하는 자료의 용량이 더 클 때, SGA에서 가장 최근까지 많이 사용된 것은 지키고, 가장 사용 안된것을 덮어써 버리는 알고리즘.

  ex) SGA 내부 구성요소 중에서 Shared pool, Database buffer cache등이 LRU 알고리즘을 이용하는 대표 구성요소이다.

Working Data Set (Working Set)
LRU List	메인 리스트	[Free / Dirty 둘다] 사용된 Buffer들의 리스트. hot영역과 cold 영역으로 나뉜다.
	보조 리스트(Free list) ★	[Free 만] 사용되지 않은 buffer들이나, DBWR에 의해 기록된 buffer들의 리스트.
LRUW List	메인 리스트(Dirty list) ★	[Dirty 만] 변경된 buffer들의 리스트
	보조 리스트	현재 DBWR에 의해 기록중인 buffer들의 리스트

 : oracle은 LRU List를 스캔의 효율성을 위해 LRU 리스트와 LRUW 리스트로 나누고, 또 각각 세부적으로 메인리스트와 보조리스트로 별도로 나눠서 관리한다. 이런 LRU List + LRUW List를 합쳐서 working Data Set (또는 working set)이라고 부른다.

 → Oracle은 대용량인 DB buffer cache를 빠르게 관리하기 위해 여러개의 구역으로 나누고 관리하는 Working Set을 여러개 생성해서 여러 사용자들이 동시에 Free buffer를 보다 빠르게 찾을 수 있도록 만들어져 있다.

 

  * 사용자가 데이터를 변경할 때 일어나는 순서

  ① 사용자가 데이터를 변경 완료(commit/rollback)

  ② 우선 Database buffer cache에서 LRU리스트의 보조리스트에서 free buffer를 찾아서 확보해둔다.(Buffer lock)

  ③ 보조 리스트(Free list)의 buffer가 모두 사용 된 경우, 메인 리스트의 cold영역에서 free buffer를 다시 찾는다.

  ④ 결국 Free buffer를 못 찾게 되면, scan을 멈추고 DBWR에게 Dirty Buffer를 내려쓰라고 요청한다.

  ⑤ Dirty buffer가 Free buffer로 상태가 바뀌면, LRU List의 보조리스트에 추가되며, 사용자가 Free block을 확보한 후 필요한 블록을 db buffer cache로 복사해온다.

   → 인스턴스가 최초로 구동된 때는 모든 buffer들이 LRU List의 보조리스트(Free list)에서 관리된다.

 

▷ oracle은 대용량인 DB Buffer cache를 빠르게 관리하기 위해, 여러개의 구역으로 나누고 각 구역을 관리하는 working Data set을 여러 개 생성해서 여러 사용자들이 동시에 free buffer를 보다 빠르게 찾을 수 있도록 만들어져 있다. (이 방법도 아주 많은 사용자들이 동시에 접속을 해서 사용하면 대기현상 때문에 작업속도가 느려진다.)

 

* Latch : 유한한 자원을 여러 process 가 한꺼번에 사용하려고 할 경우를 대비해 순서를 정해주는 역할을 한다. (은행의 번호표와 같은 역할)

 - 모든 메모리 자원에는 각 Latch가 별도로 존재하며, 하나의 메모리 공간에 여러 개의 Latch가 존재하는 경우도 있다.

 - 모든 process들은 해당 메모리 자원에 접근해서 사용하려면 반드시 그 메모리의 Latch를 가지고 있어야 한다.

  (예를들어, 데이터 변경할때 사용되는 SGA구성요소 중에 redo log buffer가 있는데, 데이터 변경하려면 반드시 이곳에 변경된 데이터를 기록해야하며, 그러기 위해서 redo copy latch라는 latch를 먼저 확보한 후, redo allocation latch를 확보해야만 내용을 기록할 수 있다.)

 

 2) Redo log buffer : 데이터에 변경사항이 생길 경우(DDL/DML) 해당 변경 내용을 기록해 두는 장부.

 - 여기에 변경내용을 기록하는 이유는 장애가 발생했을 때 복구를 하기 위해서이다. (ch6에서 더 자세히 다룸)

 - Redo Log file : Redo Log Buffer의 내용을 디스크에 저장해주는 파일

 - DDL이나 DML, TCL같은 작업내용들은 저장되지만, Select같은 조회의 경우는 저장되지 않는다.

 - Direct load(SQL Loader, insert /*+ append*/)나 table, index생성시 nologing옵션을 준다든지 하는 경우에는 기록이 되지 않는다. (단, nologging옵션으로 테이블이 생성되었다 하더라도 일반적인 insert, update, delete같은 작업은 기록됨) (Direct Load기법은 datapump에서 자세히 다룸)

Redo (다시하기)	Data가 변경될 경우 변경후의 내용을 적어둠.
Undo (취소하기) (=rollback)	Data가 변경될 경우 변경전의 내용을 적어둠.

 

3) Shared Pool : 다른사용자와 어떤 대상을 공유해서 사용하기 위해 만들어진 곳. (강사님이 안보고 넘어가심)

Shraed pool
Library cache	- soft parse할 때 사용되는 공간.  - 이미 수행되었던 SQL문장이나 PL/SQL문장의 parse code와 해당 SQL/PLSQL문장, 실행계획 등이 저장되어 있고 LRU 알고리즘으로 관리된다.
Dictionary cache	- 구문분석이나 옵티마이져가 실행계획을 세울 때 사용되는 주요 dictionary들이 Row 단위로 cache되어 있다.  - LRU 알고리즘으로 관리된다.
Server Result Cache (42~45p)	- 결과값을 cache해두는 공간. (11g)  - 장점 : 동일한 select가 수행되었을 경우 DB buffer cache 까지 가지 않고 즉시 server result cache에서 가져가도록 해서 속도를 높인다.  - 단점 : 그러나 result cache를 살펴 본 후 결과가 존재하지 않으면 다시 database baffer cache로 가서 데이터를 가져와야 하므로 시간이 더 걸릴 수도 있고, result cache에 있는 데이터 원본 값이 database buffer cache에서 다른 값으로 변경되었을 경우 result cache의 값에도 반영시킨 후 데이터를 가져와야하는 등 고려할 사항이 많다.  - 기본적으로 사용안함으로 설정되어 있고, 사용할땐 SQL문장에 /*+ result_cache */ 라는 힌트구문을 사용해서 수동으로 설정해야 한다.  또는 RESULT_CACHE_MODE 값을 Manual에서 force로 변경해두면 계속 사용한다.  - alter system set result_cache_mode=force;
Reserved pool (45~46p) (개념만정리함)	- shared pool에 5KB(11g기준)가 넘는 오브젝트가 적재되어야 할 경우에 사용하기 위해 예약해둔 공간.  - 가끔씩 java나 PL/SQL, SQL객체 중에서 대용량인 객체가 있을 경우 shared pool의 공간이 부족할 경우 사용하는 공간.

 

 

(4) Dynamic SGA 기능 (9i버전부터)

 : 관리자가 필요에 의해서 SGA의 구성요소의 크기를 변경한 후 oracle instance의 재시작 없이 즉시 적용할 수 있는 기능.(단 Redo log buffer를 포함한 몇 가지는 제외)

 

* alter system set : 해당 구성요소의 사이즈를 변경할 때 즉시 적용.

ex) >alter system set DB_CACHE_SIZE=100M; --database buffer cache크기를 100mb로 변경. 

→ 그런데 정확하게 100MB로 변경되지 않는다. 왜냐하면 단위때문에.

 

* 그래뉼(Granule) : 동적으로 크기를 바꿀 때 메모리를 할당하는 새로운 단위.

- SGA_MAX_SIZE라는 파라미터의 크기에 따라 결정된다.

 

▷ show sga : 현재 사용중인 SGA크기 확인.

- Total System Global Area : 전체 SGA 양 - Fixed Size : background process들이 사용하는 공간. (예약되어 있음.) - Variable size : shared pool, large pool, java pool로 사용되는 공간. - Database buffers : Db Buffer cache로 사용될 공간. - Redo buffers : redo log buffer로 사용될 공간.

 

* ASMM : 사용자가 SGA의 각 구성요소 값을 지정하지 않아도 Oracle이 자동으로 SGA의 값을 결정하게 해서 성능을 향상시키는 기법으로, SGA의 각 구성요소 값을 잘못 설정할 경우 성능이 저하되고 문제가 발생하므로 oracle이 스스로 최적의 값을 찾아서 사용하도록 하는 기술. (51p참조)

 

 

(5) Program Global Area(PGA)의 주요 구성 요소.

 

RAM	SGA	모든 process들이 공유해서 사용되는 메모리 공간 (ex. 학교에서 운동장 같은 개념)
	PGA	각 process들이 개별적으로 사용하는 메모리 공간 (ex. 학교에서 사물함 같은 개념)

 

- 모든 process는 각각 PGA를 다 가지고 있으므로, server process나 백그라운드process들은 전부 각각의 PGA를 가지고 각자의 용도에 맞게 사용하고 있다. (52~56p 더 자세히)