Oracle DB구조2 : Instance의 SGA 메모리구조

오라클 데이터베이스 구조

• 오라클DB는 크게 인스턴스(SGA 메모리구조와 백그라운드 프로세스와 데이터베이스로 나뉜다.

Instance	SGA (System Grobal Area) 메모리구조	Shared pool	Library cache : - 최근에 실행된 sql구문과 실행계획이 저장되는 공간 - LRU(Least Recently Used Algorithm) 알고리즘으로 관리됨. - 대소문자, 공백까지 일치가 되어야 hit됨.
			Data dictionary cache : - 최근에 사용된 DB 정의정보가 저장된 공간 - 정의정보란 file, object, 권한, 제약조건 등 - LRU(Least Recently Used Algorithm) 알고리즘으로 관리됨.
		DB buffer cache	실제 실행 작업을 하는 메모리 구조 -최근에 사용된 Data block이 저장된 곳 -LRU 알고리즘으로 관리됨
		Redo log buffer	-DB에서 발생된 변경작업의 로그정보(Redo data)가 기록되는 곳 -순환형으로 관리됨
	Background Process	PMON	- User proc fail시 진행하던 트랜잭션 롤백 및 선점하고 있던 자원과 lock을 해제함
		SMON	- Instance fail(= DB 비정삭적인 종료) 후 DB 재시작될 때 DB동기화를 시켜줌
		DBWR	- DB buffer cache의 Dirty block을 datafile로 기록함 - 체크포인트 발생시 기록함
		LGWR	- commit이 발생될 때 redo log buffer의 로그정보(= redo data)를 redo log file로 기록함
		CKPT	- 체크포인트 발생시 DBWR에게 알려줌. - DBWR기록 후 datafiles 헤더와 controlfile에 마지막 체크포인트 번호를 갱신함
Database	Database 3대파일	Data files	실제 data가 저장되는 공간 data dictionary가 저장되는 공간 datafile 정보 조회 : v$datafile(영구data), v$tempfile(임시data)
		Control file	DB의 무결성 유지/관리할 수 있는 모든 동기화정보가 기록된 공간 DB의 논리적/물리적 구조 정보, 마지막 작업번호 등이 저장 DB당 하나이상 존재 -> 최대8개까지 다중화기능제공 오라클 권장 3개 Control file 정보조회: v$controlfile
		Redolog files	DB에서발생된 변경 작업의 로그정보(Redo data)가 기록된 공간 주목적 : Datafile recovery(복구) DB당 최소 2개이상 존재 순환형 관리 Redo log Group(논리적 구조) : DB당 2개이상 Redo log Member(물리적 구조,file) : Redo log Group당 1개이상 오라클 권장사항 : Group 3개, Member 2개씩 Redolog files 정보조회 : v$log, v$logfile
	Parameter file		Instance의 정의정보가 기록된 공간 SGA할당정보, B/G proc정보 등 DB의 여러 설정 정보가 기록된 공간 위치 : $ORACLE_HOME/dbs 이름 : spfileSID.ora 또는 initSID.ora
	Password file		DB를 시작/종료할 수 있도록 인증해주는 공간. 위치 : $ORACLE_HOME/dbs 이름 : orapwSID
	Optional	Archived log files	- Redo log file의 오프라인 복사본 - 주목적 : Datafile Recovery - log mode : Narchive log mode VS Archive log mode 중 선택 - log mode 정보 조회 : v$database

SGA (System Grobal Area) 메모리구조

• 필수 메모리 구조는 3개가 있다.
  • Shared pool, DB buffer cache, Redo log buffer
• 공유가 가능한 메모리 구조.
• 실행순서 : Library cache > Data dictionary cache > DB buffer cache

Shared pool

사전 준비작업을 하는 메모리 구조

프로세스 예시

1. 유저가 접속한다. > select 구문을 날린다.
2. user proc가 구문을 받는다 : 유저의 요청을 이진정보로 변경 > 해시함수를 통해 반환된 해시value값을 server proc로 전달한다.
   • 대소문자와 공백등 완전히 똑같은 구문이라면 해시value가 동일하다.
3. server proc가 진행 : 고유한 해시값을 가지고 Library cache로 간다
   • 해시값을 대조해서 동일한 값이 있으면 hit하고 실행계획을 재사용(응답속도 향상)
   • 동일한 해시값이 없으면 miss가 되고 Library cache에 새로 생성.
4. 그 다음 Data dictionary cache로 간다.

Library cache

• 최근에 실행된 sql구문과 실행계획이 저장되는 공간
• LRU(Least Recently Used Algorithm) 알고리즘으로 관리됨.
  • 주로 사용되는 FIFO 정책이 아닌 LRU 알고리즘 방식으로 최근에 사용된 적이 없는 것부터 덮어쓴다.
  • 알고리즘과 자료구조는 복잡하지만 개별적으로 공부하면 좋다.
• 대소문자, 공백까지 일치가 되어야 hit됨.
• hit가 많을 수록 응답속도가 향상되어 DB성능이 좋아진다.
  • 개발자입장에서 어떻게 hit를 높일 수 있을까?
    • 대소문자를 어떻게 쓸지 정확히 정하고 따른다.
    • 같은 DB를 사용하는 사람들끼리 대소문자, 공백등 규칙을 정하고 따른다.
  • DBA입장에서 어떻게 hit를 높일까?
    • Library cache 메모리 사이즈를 최대한 크게 잡을 수록 HIT율은 올라간다.

Data dictionary cache

• 최근에 사용된 DB 정의정보가 저장된 공간
• 정의정보란 file, object, 권한, 제약조건 등
• 위치 : Datafiles의 1번 데이터파일
• LRU(Least Recently Used Algorithm) 알고리즘으로 관리됨
• Data dictionary cache의 hit율을 높일 수 있는 방법
  • 개발자입장 : 불필요한 쿼리구문 실행하지말 것.
  • DBA입장 : cache 메모리 사이즈를 최대한 크게 잡기.

DB buffer cache

• 실제 실행 작업을 하는 메모리 구조
• 최근에 사용된 Data block이 저장된 공간
• LRU 알고리즘으로 관리됨
• 데이터 블록 크기의 권장사항은 8k(권장사항)
  • 소규모의 데이터를 자주 캐치하는 회사라면 데이터 크기가 작은 것이 처리가 빠르다 : 2k, 4k
  • 대규모의 데이터를 자주 캐치하는 회사라면 데이터 크기가 큰 것이 처리가 빠르다 : 16k, 32k

Redo log buffer

• DB에서 발생된 변경작업의 로그정보(Redo data)가 기록된 공간
• 순환형으로 관리됨