오라클 인스턴스 구성

공유풀

:라이브러리 캐시, 딕셔너리 캐시, 컨트롤 구조를 포함하는 SGA영역

 

1) 라이브러리 캐시

- 파스(pharse)된 SQL 관련 정보를 저장 (사용자가 요청한 sql 문장을 서버프로세스가 여러 단계를 거쳐 작업할 때 사용하는 작업공간)

- 라이브러리 캐시에 저장된 SQL 문자 실행 시 파스 과정 거치지 않는다.

* 오라클은 LRU 알고리즘 사용 (파싱 및 컴파일 된 프로그램 및 프로시저를 저장함)

 

2) 데이터 딕셔너리 캐시

- DB 테이블과 뷰에 대한 정보, 구조 , 사용자등에 대한 정보가 저장되어 있음

- 파싱 과정 가운데 참조된 데이터 딕셔너리 오브젝트 정보를 저장함

 

3) Result cache

- 임의의 SQL 혹은 PL/SQL 문장을 실행하는 경우 그 결과값을 메모리에 저장 후 같은 결과값이 요청되면 이를 Result cache에서 찾아 사용자에게 반환한다.

 

데이터베이스 버퍼 캐시

- 쿼리 실행, DML 실행하면 오라클은 그 결과값을 가지는 오라클 블록을 데이터 파일로부터 물리적으로 읽어들여서 복사본을 데이터베이스 버퍼 캐시에 저장한다.

 

-데이터베이스 버퍼 캐시 내부 구조 관리

• Hash table 구조로 관리가 된다.
• 래치 획득하여 해시 체인 스캔한다. (오라클은 내부적으로 동일 시점 래치를 획득한 하나의 프로세스만 스캔한다.)
• 오라클 블록의 주소값을 오라클 블록의 클라스 정보와 Hash 함수 Input으로 입력한다. 그러면 Hash value가 함수 output 값으로 나오는데, 이 값과 해시 버켓을 스캔하여 자신의 Hash value와 같은 값을 찾는다.
• 특정 해시 버켓에 도달하면 그 해시 버켓 내부에 체인 방식으로 연결된 버퍼 헤더들을 처음부터 스캔을 하다가 찾고자 하는 버퍼가 발견되면, 일단 래치를 반환하고 해당 버퍼를 액세스한다. 
  (만약, 해당 버퍼가 사용중이라면 버퍼 Lock wait list에 등록 버퍼 락을 해제될 때까지 대기한다.)
• 작업 완료후에 버퍼 락을 해제해야 하는데, 다른 프로세스와 충돌이 발생하지 않게 cache buffer chains latch를 다시 획득한다.

버퍼 자체의 상태
-pinned : 해시 버퍼로부터 버퍼락을 획득하고 현재 작업중인 버퍼
-free : 아직 사용하지 않고 있는 버퍼로서 언제든지 사용 가능한 버퍼
-clean : 이미 사용된 적 있지만 지금은 read consistent 버전 가짐
-dirty : 데이터베이스 버퍼 캐시에서 변경되어 디스크로 내려 적히기를 기다리는 버퍼

- 버퍼의 읽기 / 쓰기 요청

• 버퍼의 읽기 요청이 들어오면 바로 그 시점 데이터를 돌려준다. read consistency를 유지하기 위해 언두로부터 언두 데이터를 생성하여 새로운 버퍼를 생성하고 그 버퍼를 사용자에게 돌려준다.
• 쓰기 요청이 들어오면 변경된 블록 이미지를 돌려준다. (트랜잭션이 커밋도지 않은 버퍼)

- 데이터베이스 버퍼 캐시 인력구성

1) Default 버퍼 풀

 - db_cache_size 파라미터 적용, 기본적으로 생성된다.

 

2) Keep 버퍼 풀

 - db_keep_cache_size 파라미터 적용

 - 자주 재사용되는 블록들을 저장하고자 하는 경우 추가적으로 생성 가능

- 별도의 공간인 keep 버퍼 풀에 자주 참조되는 테이블 데이터 저장, 관리

 

3) Recycle  버퍼 풀

 - db_recycle_cache_size 파라미터 적용

 - 자주 사용하지 않는 데이터 블록을 임시적으로 저장하게 될 공간을 설정

 

리두 로그 버퍼

: DB에서 일어난 모든 변화를 저장하는 메모리 공간

 

논리적 로그 생성 : 변경을 발생시키는 명령문과 변경사항을 롤백시킬 수 있는 명령문 사용한다.

물리적 로그 생성 : 변경 전, 후의 전체 이미지를 모두 리두 로그에 기록한다.

 

선로그 기법

DML 수행 시 데이터를 변경하기 앞서 리두 로그를 생성한다.

DBWR가 더티 버퍼를 디스크에 기록하기 전에 LGWR가 먼저 호출되어 리두 로그 버퍼의 정보를 리두 로그 파일에 기록한다.