1. 데이터베이스 아키텍처
- 오라클에서는 디스크에 저장된 데이터집합(Datafile, Redo Log File, Control File등)을 Database라고 부른다. 그리고 SGA 공유 메모리 영역과 이를 액세스하는 프로세스 집합을 합쳐서 Instance라고 부른다.-
오라클 백그라운드 프로세스정리
Shared Pool : Library Cache와 Data Dictionary Cache로 구성되어있는 메모리 영역
Library Cache : 실행코드와 실행계획을 저장하는 공간
Dictionary Cache : 테이블,인덱스,함수등의 메타정보를 저장하는 공간
DB Buffer Cache : 최근에 사용된 Data Block이 저장되는 메모리 영역(최근에 사용되지 않은 데이터블록부터 디스크에 쓰여지는 LRU알고리즘 사용)
Redo Log Buffer : 데이터의 변경사항이 생길경우 장애복구를 위해 해당변경 내용을 기록해두는 메모리영역
Server Process : SQL문을 처리하는 Process로 오라클 Client에게 직접 서비스를 수행하는 Process
DBWn : DB Buffer Cache에 수정된 블록의 내용을 데이터파일에 기록. 하고 필요한 경우 데이터파일에서 데이터를 가져오는 Process -> 잘못된거 서버프로세스가 data file에서 올린다
LGWR : DB Buffer Cache에 발생한 모든변화를 기록하는 역할 (서버 Process가 시키거나 Commit후 Redo Log File에 기록,DBWr이 디스크에 내리기전이라도 Commit이 되어있으면 Redo Log file 이용해 복구)
사용자 프로세스가 로그버퍼에 로그를 기록하고, 데이터블록을 변경한 이후 LGWR이 주기적으로 로그버퍼 엔트리를 REDO 로그파일에 기록
ARCn : Rog Switch가 발생(이 때 체크포인트 발생) 시 Redo Log File을 Archived Log File로 복사
CKPT : Memory내의 데이터와 데이터 파일에 저장된 데이터를 일치시키도록 DBWn에게 명령을 하고 체크포인트가 발생하면 데이터파일과 컨트롤파일의 헤더를 갱신
PMON : 정상적으로 작동하지 않는 프로세스들을 감시하여 종료시킴
SMON : 오라클 Instance를 복구하며 관리하는 역할 -
데이터 저장구조
블록(=페이지) : 대부분 DBMS는 블록단위 I/O, 하나의 블록에서 하나의 컬럼만 읽어도 속한블록 전체를 읽게됨.
익스텐트 : 공간을 확장하는 단위. 테이블이나 인덱스에 데이터를 입력하다가 공간이 부족해지면 해당 오브젝트가 속한 테이블스페이스(물리적으로는 데이터파일)
로부터 추가적인 공간을 할당받는데, 이때 정해진 익스텐트 크기의 연속된 블록을 할당받는다.
세그먼트 : 데이터 저장공간을 사용하는 오브젝트(테이블,인덱스, 파티션, 클러스터,LOB)를 저장공간을 사용하지 않는 오브젝트(뷰, 시너님, 시퀀스, 함수, 프로시저, 트리거)와
구분해서 세그먼트라고 부른다. 저장공간을 사용한다는것은 테이블스페이스로부터 한개이상의 익스텐트를 할당받음을 뜻한다.
세그먼트는 익스텐트의 집합, 익스텐트내 블록이 논리적으로 서로 인접한 반면, 익스텐트끼리 서로 인접하지는 않는다.
테이블 스페이스 : 세그먼트를 담는 컨테이너로서, 여러개의 데이터파일로 구성, 각세그먼트는 정확히 한 테이블스페이스에 속하지만, 한테이블스페이스에는 여러 세그먼트가 존재할수있다.
한 세그먼트는 여러 데이터파일에 걸쳐 저장된다. 한 테이블스페이스가 여러 데이터 파일로 구성되기 때문이다. -
트랜잭션, Redo, Undo : https://brownbears.tistory.com/181
-
Undo 사용 목적 (TTR): Rollback을위함, Undo세그먼트도 익스텐트단위확장
1) Transaction Rollback - 트랜잭션에 의한 변경사항을 최종 commit하지않고 롤백할때 Undo 데이터이용
2) Transaction Recovery (->Instance Recovery시 rollback단계) - Instance Crash발생후 최종커밋되지않은 변경사항까지 모두 복귀, 시스템 셧다운시 커밋안된트랜잭션 모두 롤백.
3) Read consistency. - 읽기 일관성 -
Redo 사용목적 (DCF) : 데이터 파일/컨트롤파일에가해지는 모든 변경사항을 하나의 Redo로그에 기록
Online Redo와 Archived(=Offline) Redo로그로 구성된다
Online Redo로그 : Redo로그 버퍼에 버퍼링된 로그 엔트리를 기록하는 파일로 최소두개이상파일로구성, 현재사용중 Redo로그 꽉차면 다음 Redo로그파일로 로그스위칭
모든 Redo로그파일이 꽉차면 다시첫번째 Redo로그파일부터 재사용하는 Round-Robin방식
Archived Redo 로그 : Online Redo로그가 재사용되기전에 다른위치로 백업해둔 파일.
1) Database Recovery(Media Recovery) : 물리적으로 디스크가 깨지는등의 Media Fail발생시 데이터베이스 복구하기위해 사용, 이때 Archived Redo로그 이용.
2) Cache Recovery(->Instance Recovery시 roll foward단계)
- DB시스템이 버퍼캐시를도입하는것은 I/O성능향상을 위함 BUT 버퍼는 휘발성 > 디스크상 데이터 블록에 기록되기전에 정전등이 발생해 인스턴스가 비정상적 종료되면>
그때까지 작업내용을 모두 잃는다 > 이러한 트랜잭션 데이터 유실에 대비하기 위해 REDO로그사용. - Instance Crash후 시스템 재기동 > Online Redo로그에 저장된 기록사항 읽어 마지막 체크포인트 이후부터 사고발생직전까지 수행된 트랜잭션 재현 >
버퍼캐시에만 수정하고 데이터파일에는 반영되지않았던변경사항들이 복구 = 트랜잭션 커밋여부 불문 일단 버퍼캐시를시스템 셧다운 이전상태로 되돌리는것. >
Cache Recovery가 완료되면 Undo데이터 이용해 시스템 셧다운되는시점에 커밋되지 않았던 트랜잭션을 모두 롤백(Transaction recovery=rollback) >
이렇게 roll foward, rollback단계가 모두 완료되고나면 커밋되지 않은 기록사항들은 모두 제거되어 데이터파일에는 커밋에 성공한 데이터만 남게되며 데이터베이스는 완전동기화된 상태.
3) Fast commit - Redo로그만믿고 빠르게 커밋완료
- 변경된 메모리 버퍼 블록을 디스크상의데이터블록에기록하는 작업은 Random액세스 방식으로 이루어지기 때문에 느리다 >
반면 로그는 Append방식 기록이라 상대적으로 매우 빠름 > 트랜잭션발생시 건건이 데이터 파일에 기록하기보다 우선변경사항을 Append방식으로 빠르게 로그파일에 기록하고
메모리 데이터 블록과 데이터 파일간 동기화는 적절한수단(DBWR, checkpoint)을 이용해 나중에 배치 방식으로 일괄수행
* 추가로 Delayed 블록 클린아웃도있음
-
오라클 메모리 구조 (SGA, PGA) - https://1duffy.tistory.com/18
SGA(System Global Area) : 공용 메모리 영역, DB접속하는 모든 사용자는 동일 SGA사용, 모든 사용자가 공유가능하여 사용
공유풀(SHARED POOL), 데이터 버퍼캐쉬, REDO 로그 버퍼로 구성
PGA(Program Global Area) : DB접속하는 모든 유저에게 할당되는 각각의 서버 프로세스가 독자적으로 사용하는 오라클 메모리 영역, 사용자마다 공유하지 않고 개별적으로 사용.
Sort Area, Session Information, Cursor State, Stack Space
