SQLP 노트 정리본 📚
1. 기본 아키텍쳐
1) 데이터베이스
: 데이터를 저장하는 파일 집합 = 디스크에 저장된 데이터 집합
2) SGA 공유 메모리 = 캐시 영역
(1) DB 버퍼 캐시 ━━━━━━━━━━━┐
(2) Redo 로그 버퍼 ━━━━━━ 데이터 입출력을 빠르게 하기 위함
(3) Shared Pool
① 데이터 딕셔너리 캐시 ━━━━━━━┛
= 로우 캐시 (∵로우 단위 I/O)
② 라이브러리 캐시
3) 프로세스
(1) 서버 프로세스 → DBMS
(2) 백그라운드 프로세스 : DBWn, LGWR, SMON, PMON, RECO 등
⭐ 인스턴스 = SGA 공유 메모리 + 프로세스
※ 오라클 접속 과정
2. DB 버퍼 캐시
⭐ 래치 Latch
: SGA에 공유된 자료구조를 보호하기 위해
엑세스를 직렬화하는 Lock 메커니즘
- 캐시버퍼체인 래치 : 여러 해시체인 관리
- 캐시버퍼 LRU체인 래치 : LRU리스트 보호
3. 버퍼Lock
버퍼블록 읽기
DBA → 해시버킷 → 해시체인래치 획득
→ 버퍼블록을 찾았으나, 다른 프로세스가 버퍼Lock
→ 버퍼헤더에 있는 버퍼Lock 대기자목록에 등록
→ 래치 해제 → buffer busy waits 이벤트 발생
⌈버퍼⌉ → 캐시된 버퍼핸들이 다 사용중이면 cache buffer handles래치 획득
|Lock| → 버퍼핸들 획득
⌊획득⌋ → 버퍼헤더에 있는 소유자목록에 버퍼핸들 연결 즉, pin 설정
버퍼Lock의 필요성
: 오라클은 블록단위 I/O를 수행하므로, 블록 자체로의 진입을 직력화해야 정합성 유지 가능
버퍼 Pinning
: 하나의 DB call동안 버퍼Pin 유지
→ 래치 획득 과정 생략하여 논리적 블록 읽기 횟수 ⇓
ex1) 인덱스 스캔 중, 인덱스와 테이블 교차 방문 시
ex2) 인덱스 스킵스캔 중, 인덱스 브랜치 블록 pinning
4. Redo
Redo 목적
1) DB 복구
: 디스크가 깨지면 Achived Redo 로그 사용
2) 캐시 복구
: 정전으로 인스턴스 종료되면 Online Redo 로그로 트랜잭션 재현 (인스턴스 복구 시 Roll forward 단계)
→ 이후 롤백해서 트랜잭션 복구
3) Fast Commit
: 커밋 시 Redo 로그를 append하고, 데이터파일에는 나중에 기록
데이터 블록에 커밋정보를 기록하고,
로우 Lock 해제를 지연시킴 (Delayed Cleanout)→ 오라클은 Lock매니저없이 레코드 속성으로 Lock을 구현하므로, 일일이 레코드를 찾아 Lock을 해제하는 것은 비효율적
LGWR가 Redo 로그를 기록하는 시점
1) 커밋 or 롤백 명령 시 (Log Force at Commit)
: 트랜잭션의 영속성 보장
2) 3초마다 DBWR로부터 신호를 받을 때 (Write ahead logging)
: Dirty 버퍼를 파일에 기록하기 전 로그 먼저 기록
(Instance crash가 발생하여 roll forward 후 rollback을 하는 과정에서, 데이터파일에는 있으나 Redo 로그에는 없으면 롤백이 아닌 커밋이 됨)
3) 로그버퍼의 1/3이 차거나, 1MB가 넘을 때
: 대량 트랜잭션 대비
5. Undo
Undo 목적
1) 트랜잭션 롤백
2) 트랜잭션 복구 (인스턴스 복구 시 rollback 단계)
3) 읽기 일관성 Read Consistency ⭐
Transaction Table Slot
: 트랜잭션 시작을 위해 확보해야 함
① 트랜잭션 ID ② 커밋 SCN
③ 트랜잭션 Status ④ Last UBA
Interested Transaction List Slot (ITL Slot)
① 트랜잭션 ID ② 커밋 SCN
③ UBA ④ 커밋 Flag
⑤ Locking 정보 (트랜잭션 진행을 위해 확보해야 Blocking되지x)
Lock Byte
: 해당 레코드를 누가 갱신 중인지?!
= 트랜잭션의 ITL 슬롯 번호 (포인터)
참고 도서 : 오라클 성능 고도화 원리와 해법 1
