justdoit

(1) 메모리와 디스크

​

​

​

​

● INSTANCE (작업)

메모리 부분에 생성되는 구조

실제 작업하는 장소

오라클은 메모리를 나눠서 관리

- SGA(System Global Area)

실제 작업장소(공유메모리)

​모든 조회나 대부분의 작업이 이루어짐

-​ Background Process

오라클 서버가 잘 운영되도록 해주는 역할

​

​

​

​

​

● DATABASE (저장)

- 데이터가 저장되는 데이터 파일

- DB 전체의 관리정보가 들어있는 컨트롤 파일

​- 장애 복구 시 사용되는 Redo 로그파일

(2) Instant 할당 및 관리

​

● Instance 생성과정

1. startup 요청을 받은 최초의 Oracle Server process가 초기화 파라미터(pfile 또는 spfile)에 적혀있는 설정을 참고해 OS kernel에게 공유메모리를 사용할 수 있도록 할당해 달라고 요청

2. 요청받은 kernel은 자신의 OS kernel 파라미터를 조회해 그 파일들에 설정되어 있는 내역으로 공유메모리(SGA)할당

3. 세마포어 설정 값 등을 기반으로 커널이 관리를 시작

(Server process가 종료되어도 SGA는 종료되지 않고, Instance가 종료되야 SGA가 공유메모리에서 사라짐)

● Kernel

- 모든 하드웨어를 관장 (RAM을 사용해 작업하려면 kernel에게 허락받아야 함)
- RAM 하나를 여러 프로그램이 공유해서 사용하므로 스케줄링 잘못하면 같은 메모리를 덮어쓸 수 있음 →블루스크린, kernel panic 초래

- 커널이 메모리 관리를 잘 해야 성능이 좋아짐
- 오라클이 요청한대로 메모리를 할당해 주는것이 아니라 커널의 설정파일에 적혀있는대로 할당(​만약, 서버의 총 RAM이 1G인데, 오라클이 2G를 요구할 수도 있기 때문)

○ linux 커널값 적는 파일    /etc/sysctl.conf

○ solaris 커널값 적는 파일   /etc/system

​  

>> 예로, 오라클이 1G를 요청해도 /etc/sysctl.conf 파일에 500MB만 허락하도록 적혀있다면 그만큼만 할당해줌

>> 물리적으로 RAM을 추가해도(10G→30G) 설정파일의 값을 바꾸지 않는다면 프로그램이 사용하는 메모리는 변화 없음

​

● 공유메모리 관리​

​- 모든 Server process들이 동시에 함께 RAM(공유메모리)을 사용하기 때문에, 하나의 메모리 블록을 여러 프로그램이 동시에 중복 사용하는 사태를 막기 위해 OS차원에서 제공하는 세마포어와 몇가지 Kernel 파라미터들이 존재함

​   

- 세마포어(Semaphore) : 깃발(flag)이란 의미로 어떤 자원의 현재 사용 여부를 표현 set / unset, ​셋트로 여러개씩 사용함

1. 사용할 메모리블록의 세마포어 상태를 먼저 확인함

2. 만약, 사용중(set)으로 설정돼있으면 Process는 대기하고 있다가 블록이 release되어 unset이 되는 순간에 세마포어를 set으로 설정함 -> 메모리블록 사용가능

- Kernel 파라미터 : 유닉스계열 OS별로권장 수치는 다를수 있음

● 커널이 위의 파라미터들을 기초로 해서 Oracle에 공유메모리를 할당하는 3가지 방법

1. 물리적 메모리 충분할 경우 : 하나의 세그먼트에 전체 SGA 할당
2. 하나의 세그먼트에 할당 할수 없는 경우 : 연속된 여러 세그먼트로 분산시켜 할당
3. 연속으로 할당 할수 없는 경우: 불연속적인 여러 세그먼트에 분산시켜 할당

( Fixed Area 부분은 반드시 전체가 1개의 세그먼트에 할당 되어야 함 )

(3) SGA 주요 구성요소

Oracle Server process가 SGA를 생성하기 위해 커널에게 공유메모리를 할당 받아온다. 그 후 파라미터 파일과 각종 사항을 참고해서 SGA를 이루고 있는 구성 요소들을 생성함.

- 필수 구성요소 : DB Buffer Cache, Redo Log Buffer, Shared Pool 

● Database Buffer Cache

​- 데이터의 조회와 변경 등의 실제 작업이 일어나는 공간

- 사용자가 조회하거나 변경하려는 모든 데이터는 이 곳에 있어야 하고, 없을경우 HDD의 데이터 파일에서 해당 내용이 들어있는 Block을 복사해서 가져옴 (그렇게 하기위해서는 Buffer Cache의 Block 상태를 먼저 확인해야함)

- 여러명의 사용자가 이 곳을 공유해서 사용하므로 하나의 메모리 Block을 여러 사용자가 동시에 I/O 하는 것을 방지하기 위해 오라클은 Buffer Cache Block의 상태를 확일할 수 있는 LRU(Least Recently Used) List를 통해 관리하고 있음

- LRU 알고리즘 : 공유메모리의 공간은 용량이 제한적이므로 SGA의 일부분을 덮어 써야 하는 경우가 생길 수 있는데, 이때 무작정 덮어 쓰는 것이 아니라 가장 최근까지 사용된 것은 지키고 가장 사용이 안된 것은 버리는(덮어쓰는) 알고리즘.

- 오라클은 LRU List 스캔의 효율성을 위해 LRU List와 LRUW List로 나누어 관리하고 있음

(Working Data Set 혹은 Working Set = LRU List + LRUW List)

- 사용자가 데이터파일의 데이터를 DB Buffer Cache로 복사해와야 할 경우에 복사하기전 우선 먼저 LRU 보조 리스트에서 free buffer를 찾아서 확보해야함. 만약 보조 리스트의 free buffer가 모두 사용된 경우, LRU 메인 리스트 Cold 영역에서 free buffer를 다시 찾음

- 특정개수(10g 기준 40%)만큼 찾았는데 못찾으면 scan 멈추고 DBWR^[각주:1]한테 dirty buffer 내려쓰라고 요청함

- 변경내용을 저장안한 dirty buffer는 DBWR에 의해 데이터파일로 저장이 완료되어 free buffer로 바뀌게 되고 LRU list의 보조리스트에 추가됨.

- 이제 사용자는 free buffer를 확보한 후 데이터 파일에서 필요한 블록을 DB Buffer Cache로 복사해 올 수 있게됨.

(HDD의 데이터파일에서 필요한 블록을 찾아 Buffer Cache로 복사해 오는 작업은 Server process가 함) 

* Instance 최초 구동시 모든 buffer들은 LRU List의 보조리스트에서 관리됨

- 위에서 살펴본 List들은 모든 사용자가 공유해서 사용하기 때문에 한번에 여러 Server process들이 동시에 이 List를 사용하려고 시도할 수 있음. 그래서 오라클은 일반적으로 대용량인 DB Buffer Cache를 빠르게 관리하기 위해 여러 구역으로 나누고 관리하는 WorkingSet을 여러개 생성해 여러 사용자가 동시에 free buffer를 찾을수 있도록 함.

- 유한한 자원을 여러 process가 한꺼번에 사용하려고 할 경우 사용 순서를 관리하기 위해 Latch^[각주:2]를 사용

● Redo Log Buffer

- 데이터에 변경사항이 생길경우(DDL이나 DML 실행될 경우) 해당 변경 내용을 기록하는 메모리공간(장애 발생시 복구하기위해)

- Redo Log File이 Redo Log Buffer의 내용을 디스크로 저장함.

- 모든 변경사항이 전부 이곳에 기록되는것은 아님.

ex) Direct Load(SQL Loader, insert /*+APPEND*/)나 table이나 index 생성시 nologging 옵션을 주는경우에는 Redo Log에 기록되지 않음. (단, nologging 옵션으로 생성된 table이라도 일반적인 insert, update, delete 같은 작업은 모두 기록됨)

● Shared Pool

- 다른 사용자와 어떤 대상을 공유해서 사용하기 위한 공간

- Shared_Pool_Size 파라미터(동적파라미터라서 DB를 종료하지 않아도 alter system set으로 사이즈변경가능)로 전체크기 설정가능.

- Library Cache나, Dictionary Cache 크기는 각각 따로 관리 할 수 없음

● Large Pool

- 필수 구성 요소 X, 특정 기능 사용할 경우에만 사용

- shared server mode로 오라클 서버를 운영할 경우 UGA를 이곳에 생성함

- 병렬처리 작업을 할 경우 각 프로세스들간의 메세지 buffer를 이곳에 생성

- RMAN으로 백업이나 복구할 경우 RMAN이 사용하는 I/O용 buffer가 이곳에 생성됨

● Java Pool

- java 관련 code나 Java Virtual Machine(JVM) 관련 데이터를 저장하기 위해 생성되는 선택적인 공간

● Streams Pool

- 10g 이상 버전부터 생긴 SGA 구성요소로 Streams 기능을 사용할 경우에만 사용됨.

● Fixed SGA

- 오라클이 내부적으로 사용하기 위해 생성시키는 공간

- 주로 백그라운드 프로세스들이 필요한 데이터베이스의 전반적인 공유 정보나 각 프로세스들끼리 공유해야만 하는 Lock 정보 같은 내용들이 저장됨.

- 이 공간의 크기는 오라클이 시작될 때 자동으로 설정되며 사용자나 관리자가 임의로 변경X

(4) Dynamic SGA 기능(9i~)

- 관리자가 필요에 의해 SGA의 구성요소의 크기를 변경한 후 오라클 인스턴스의 재시작 없이 즉시 적용할 수 있는 기능

(단, Redo Log Buffer를 포함한 몇가지는 제외)

- 8i 버전까지는 SGA의 각 구성요소 크기를 변경하고 나서 오라클 인스턴스를 중단했다가 재시작해야만 변경사항이 적용되는 Static SGA 방식이었음.

- 오라클에서 동적으로 메모리를 할당할 때 사용하는 단위: 그래뉼(Granule)

- 10g 이후 버전기준 SGA_MAX_SIZE가 1GB 이하면 1Granule이 4MB, 1GB 초과면 1Granule이 16MB가 됨

● 관련 파라미터 

SGA_MAX_SIZE

SHARED_POOL_SIZE

DB_CACHE_SIZE

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

- 각 프로세스들이 개별적으로 사용하는 메모리 공간

- 모든 서버 프로세스들은 각각의 PGA를 가짐

- 주로 정렬관련 작업등이 이루어짐

● Private SQL Area

- Persistent Area와 Runtime Area로 나뉨

- 사용자가 SQL 문장을 수행하면 User Process가 Server Process에게 해당 쿼리를 전달해 주는데 이때 Server Process가 자신에게 작업을 요청한 User Process의 정보를 Session Memory부분에 저장을 한 후 해당 SQL을 Parse함

- 해당 SQL에 Bind 변수 등이 있을경우 해당 Bind변수값을 Persistent Area에 저장함

- 쿼리의 실행 상태정보와 쿼리를 수행하면서 임시로 정보를 저장해야 하는 경우 Runtime Area에 저장함

● SQL Work Area

- Sort 관련 작업(Sort Area)이나 Hash 관련 작업을 수행하는 공간

- 9i부터 PGA크기를 Oracle Server가 자동으로 관리할 수 있음

- 관련 파라미터

 PGA_AGGREGATE_TARGET= PGA 총량 지정

 WORKAREA_SIZE_POLICY=AUTO (동적관리), MANUAL (수동관리)

* 1개의 개별 Server Process가 쓸 수 있는 PGA 메모리량

 _SMM_MAX_SIZE

- 현재 서버의 PGA관련값 조회

 SYS> SELECT * FROM v$pgastat;