3.1 캐시가 필요한 이유

- 오라클은 디스크에서 데이터를 읽고 씀

- 디스크는 속도가 느리기 때문에 오라클은 캐시를 활용해서 가능하면 느린 디스크 대신, 빠른 메모리에서 처리하려 함

 

3.2 캐시란?

- 빈번하게 사용하는 데이터를 매번 디스크에서 가져오지 않고, 캐시라고 하는 메모리 상의 공간에 두고 빠르게 접근할 수 있음

- 캐시에 hit에 하지 않으면, 디스크에서 데이터 처리를 해야 하므로, SQL의 속도가 느려짐

 

1) SELECT요청

2) 서버 프로세스는 SELECT에 필요한 데이터가 캐시에 있는지 확인

3) 있으면, 캐시에서 가져와서 결과 반환 / 없으면, 디스크에서 읽고 캐시에 넣은 뒤에 결과를 반환

 

3.3 데이터는 블록 단위로 관리

- 오라클은 '블록'이라는 단위로 데이터를 관리하며, I/O의 단위도 블록이고, 버퍼 캐시도 블록 단위

- 한 개의 블록에는 여러 건의 데이터가 있는데, 그중 하나만 읽으려고 해도 블록 전체를 가져오고 캐시에 보관됨

- 블록의 크기는 2KB, 4KB, 6KB, 8KB, 16KB, 32KB 중 하나인데 주로 8KB

 

3.4 캐시와 인덱스

- 인덱스도 블록으로 구성됨, 인덱스를 한 블록에 보관할 수 없으면, 여러 개의 블록으로 구성함

- 인덱스도 캐싱되어 빠르게 접근할 수 있음

 

3.5 프로세스는 캐시를 공유

- 기본적으로 프로세스는 독립적으로 수행되고, 자원도 독자적으로 사용함

- 프로세스마다 캐시를 가지게 되면, 낭비가 심하고, 다른 프로세스에서 확인이 불가능함

- 오라클의 캐시는 모든 프로세스가 확인이 가능함

- OS의 공유 메모리(SGA)라는 특수한 메모리를 사용하면, 특정 프로세스가 기록한 데이터를 다른 프로세스도 확인이 가능함 (공유하지 않는 메모리 : PGA)

- DBMS에서는 여러 개의 프로세스가 실행되므로,  공유 메모리는 필수적

- 공유 메모리는 누구든지 접근이 가능하므로 Lock이 필요함 > 성능 문제 발생 가능

- 공유 메모리에는 버퍼 캐시 말고 공유 풀, 로그 버퍼 같은 영역도 있음

 

3.6 공유 메모리 설정

- 오라클 설정 파일 : sqfileXXXX.ora > DB_CACHE_SIZE : 오라클 버퍼 캐시의 크기

- 버퍼 캐시의 크기를 DBMS 성능과 직결되므로, 잘 설정해야 함

=> 오라클 설치 시 적절 크기를 알 수 없을 때 크게 정해 놓고, 나중에 통계를 기반으로 조정

=> 버퍼 캐시 어드바이저(V$_CACHE_ADVICE) : 버퍼 캐시 크기마다 물리 읽기 수를 예측

=> 버퍼 캐시 히트율 : 버퍼 캐시 내에서 요청받은 블록을 꺼내온 빈도

=> 자동 공유 메모리 관리 : SGA크기만 정해두면, 버퍼 캐시 크기를 설정할 필요 없이, 부하의 정도에 따라 오라클이 자동을 조절, DB_CACHE_SIZE를 지정하면 하한으로 동작함(최소한의 버퍼 캐시 보장)

 

3.7 공유 메모리는 어떤 식으로 보이는가?

- ps 명령어를 사용하여 각 프로세스가 사용하는 메모리의 크기를 확인할 수 있음

- VSZ : 각 프로세스의 가상 메모리 크기

- RSS : 각 프로세스가 실제로 사용하는 메모리 크기

 

세마포어

- OS가 제공하는 자원을 관리하기 위한 장치

- 자원의 수에 비해 사용하고자 하는 프로세스의 수가 많을 경우 순서대로 자원을 사용할 수 있도록 프로세스 제어를 수행

- 오라클을 기동할 때 세마포어가 부족하다는 의미의 메시지가 나타나면 늘리는 것을 검토

- 아무도 사용하지 않는 세마포어가 OS에 남아 있는 경우도 있으므로 정리(ipsc명령, ipcrm명령)

# /sbin/sysctl -a | grep sem

kernel.sem = 250 32000 100 123

 

3.8 버퍼 캐시를 정리하는 LRU 알고리즘

- 버퍼 캐시는 자주 사용하는 데이터를 더 빠르게 가져오기 위해 사용

- 그 크기를 한정되어 있으므로, 누군가 관리하고 정리를 해줘야 함

- LRU(Least Recently User) 알고리즘은 단순히 말해서 최근에 사용하지 않은 데이터부터 캐시에서 제거하는 알고리즘

- 오라클도 버퍼 캐시 관리를 위해서 LRU알고리즘을 사용

- 오라클은 큰 테이블이라고 판단하면 버퍼 캐시로 데이터 블록을 적재하지 않음

- 풀 스캔한 데이터는 일반적으로 버퍼 캐시에 적재되지 않는 다고 생각하면 됨

 

3.9 OS와 스토리지

- 스토리지 캐시 : 스토리지에서 데이터를 읽어오는 것을 빠르게, 기록하는 것도 빨라짐 (원래 디스크에 기록해야 하는 데이터를 캐시에 기록하는 것만으로 OS관점에서 I/O를 종료할 수 있음)

CPU - 메인 메모리 - | - 스토리지 캐시 - 디스크

 

3.9.1 OS의 버퍼 캐시와 가상 메모리의 차이

- OS에는 버퍼 캐시와 가상 메모리가 있음

- OS의 버퍼 캐시는 오라클의 버퍼 캐시와 유사한 기능

- OS버퍼 캐시 : 메인 메모리의 일부를 버퍼 캐시로 사용하고, 자주 사용하는 파일 데이터를 둠

- 가상 메모리 : 실제로 가진 물리 메모리보다 더 많은 메모리를 사용, 최근에 사용하지 않은 데이터를 프로세스 모르게 디스크에 보관(page out) 해두고, 나중에 요청이 들어오면 디스크에서 가져옴(page in)  메모리가 실제 메모리보다 많은 것처럼 보임 (SWAP : 가상 메모리를 위한 디스크)

- 가상 메모리와 버퍼 캐시의 동작은 상반되어 있음, 버퍼 캐시는 디스크에 빠르게 접근하기 위해 메모리의 일정 부분을 할당하여 사용하고, 이에 비해 속도가 느리더라도 사용할 수 있는 메모리의 크기를 늘리기 위해서 디스크를 사용하는 것이 가상 메모리

'DATABASE > oracle' 카테고리의 다른 글

Oracle 메모리 (undo, redo, archive)  (0) 2023.06.04
Parallel Processing  (0) 2023.06.04
[Oracle] 9. REDO와 UNDO  (0) 2021.07.23
[Oracle] 2. 오라클의 여러 프로세스  (0) 2021.07.12
[Oracle] 1. I/O와 디스크의 관계  (0) 2021.07.12