그림으로 공부하는 오라클 구조

yarn

오라클을 이해하기 위한 필수 키워드

• 병렬 처리를 가능케 하고 높은 처리량을 실현한다.

• 응답(Response)을 중시한다.

• Commit 한 데이터는 지킨다.

오라클과 하드디스크

• 오라클은 디스크로부터 데이터를 읽어오고, 처리 후 다시 디스크에 쓴다.

• 하지만 원하는 데이터를 찾아서 읽는 부분이 생각보다 오래 걸린다.

• Disk I/O는 필요한 부분 이지만 가능한 줄여야 하는 부분.

Sequential 과 Index

• Sequential • 시작점에서 마지막까지 전부 access

• 풀스캔

• Index • 책에서 사용하는 색인

• 사용하는 키 값과 그 키가 존재하고 있는 위치를 기록하여 사용

Index 사용 예제

SELECT * FROM TABLE WHERE 이름 = ‘충현’;

• 이름이 실려있는 인덱스를 조사.

• 결과로 주소(ROWID)를 얻어옴

• 그 주소를 토대로 데이터를 읽어옴.

Index 크기가 커지면..?

• Index의 자체의 크기가 커지면 똑같이 주소를 찾는데 시간이 걸리지 않을까?

• Index는 Index에 Index를 붙이는 형태로 Index를 여러단계로 구성.(tree 구조)

키 주소

바 – 비 부 – 베 보- 뵤

30 31 32

키 주소

비라 - 비리 비루 - 비로

150 151

키 주소

빌 501

30번 주소의 블록 151번 주소의 블록

오라클의 프로세스

• SQL문을 처리하는 서버 프로세스와 서버 프로세스를 도와주는 백그라운드 프로세스로 구성.

백그라운드 프로세스와 역할

• 백그라운드 프로세스와 역할 • Ora_dbwX_XXXXXX 데이터를 디스크에 기록

• Ora_lgwr_XXXXXX 로그(데이터갱신 이력)를 디스크에 기록

• Ora_pmon_XXXXXX 프로세스를 감시 및 장애 발견 시 정리 하는 역할

• Ora_arcX_XXXXXX 로그 데이터를 아카이브(장기 보관하기위 별도의 파일로 보관.)

• X에는 0이나 1 같은 숫자가 들어감.

DB가 수행하는 주요 처리

• SQL문의 수신 • SQL문의 파싱 • 데이터 읽기 • 데이터 기록 • SQL문의 결과 회신 • 로그기록 • 각종정리(락해제) • 로그보관(아카이브)

서버 프로세스 백그라운드 프로세스

캐시가 필요한 이유

• 매우 느린 Disk I/O

• 빈번하게 사용되어지는 데이터는 캐시에 두어 빠르게 사용

• 가능한 Disk에서 처리보다 빠른 캐시에서 처리.

• 오라클에서는 데이터 캐시를 버퍼캐시로 부름

버퍼캐시에 데이터가 없을때

서버 프로세스

1. SELECT

버퍼캐시

2. 버퍼에 있는지 확인

3. 디스크에서 읽어옴

4. 읽은 데이터를 버퍼에 보관

5 결과

버퍼캐시에 데이터가 있을때

서버 프로세스

1. SELECT

버퍼캐시

2. 버퍼에 있는지 확인 3. 데이터를 빠르게 가져옴

4 결과

데이터는 블록 단위로 관리

• I/O 단위도 블록 기반

• 버퍼캐시도 블록단위로 관리

• 블록 크기는 2KB, 4KB, 8KB, 16KB, 32KB

• Index 또한 블록으로 구성

오라클 블록 구조

블록 헤더 (관리영역)

데이터는 아래부분 부터 채워짐

블록 헤더 (관리영역)

삭제된 공간

삭제된 공간은 다시 채우지 않는다. (단 PCTUSED or ASSM 사용시 공간 여유도에 따라 채워짐

프로세스는 캐시를 공유한다

• 프로세스 마다 캐시를 갖는것은 낭비

• 기본적으로 다른 프로세스의 메모리를 보는것은 불가능

• OS의 특수한 메모리기능 ‘공유메모리’를 이용.

• 오라클에서는 공유 메모리를 SGA(System Global Area), 공유하지 않는 메모리를 PGA(Private Global Area).

공유 메모리

• 다른 프로세스의 공유메모리는 접근 불가

• 하나의 프로세스에서 공유메모리 변경 시 다른 프로세스 공유메모리에 반영

• 누구든지 접근 가능하므로 락을 걸어서 배타 제어, 그래서 많은 락이 존재, 성능 저하에 영향

버퍼캐시 정리

• 일반적으로 LRU (Least Recently Used) 알고리즘을 사용

• 최근에 사용하지 않은 데이터 부터 정리

• 풀스캔 데이터는 버퍼캐시에 적재 되지 않음

• 오라클에서는 변경한 데이터를 바로 디스크에 기록하지 않고 캐시에 두고 dbwr프로세스가 디스크에 기록함, 하지만 캐시에 정리될수 있으니 dbwr프로세스가 정기적으로 디스크에 기록함.

SQL문과 일반 프로그래밍언어의 차이

• SQL문은 처리 방법을 기술하지 않는다

• 옵티마이저(파서)가 SQL문을 분석하고 실행계획을 생성하여 처리

• 실행계획에는 인덱스 사용여부,테이블의 검색순서 조인방법이 포함

오라클 알고리즘

• 규칙기반 (Rule base)

• 10g부터 규칙기반은 지원하지 않음

• 비용기반 (Cost base)

• 처리 시간이나 I/O 횟수가 가장적은 방법 기준으로 처리

통계정보

• 비용을 계산하기 위한 기초적인 정보

• SQL문의 정보

• 테이블이나 Index 통계정보

• 파라미터 정보

• 시스템 통계정보

• 통계수집(dbms_stats)을 통해서 수집

공유풀의 동작과 구조

• SQL문을 분석하는데 많은 비용이 소모되기 때문에 이미 사용한 실행계획을 재 사용함

• 공유 메모리에 존재

• Library cache 와 Dictionary cache 영역으로 구분

동일한 SQL문 판단 기준

• 오라클은 해시 알고리즘을 사용해서 SQL문의 ID를 생성

• 대소문자 구분 Select * from table_name where a=‘1’

SELECT * from table_name where a=‘1’

• 검색조건의 값이 다른 SQL문은 바인드 변수를 사용하면 같은 SQL로 판단

Select * from table_name where a = :A

서로 다른 SQL문

분석(parse)의 종류

• Hard parse

• 공유풀에 실행계획이 없으면 실행계획을 생성

• Soft parse

• 공유풀에 실행계획이 있을 경우 그 실행계획을 재사용

오라클의 connection

• TCP/IP 구조

• 오라클에서 수신을 기다리는 프로세스를 listener (서버 프로세스가 아님)

Connection 동작 순서

1. Listener를 기동한다. ① listener.ora 참조 ② lsnrctl 도구를 사용해서 기동

2. 클라이언트에서의 connection ① tnsnames.ora 참조 ② tnsnames.ora의 식별자를 통해 linstener 사이의 소켓을 생성 ③ tnsnames.ora을 참조 하지 않아도 접속가능.

3. 서버 프로세스의 생성 ① 서버 프로세스 생성 및 소켓 인계

오라클 데이터 구조

테이블 스페이스 테이블이나 인덱스등을 보관하기 위한 공강

세그먼트 테이블이나 인덱스등의 데이터를 보관

익스텐트 관리를 쉽게 하기 위한 오라클블록의 집합

오라클 블록 관리를 쉽게 하기 위한 데이터의 집합

데이터 파일

블록

테이블 스페이스는 1개이상의 세그먼트를 보관 할 수잇다.

테이블 스페이스는 1개이상의 데이터파일 로 구성된다.

세그먼트는 한 개 이상의 익스텐트 (블록의 집합)로 구성된다

익스텐트는 여러 개의 연속된 오라클 블록으로 구성. 오라클 블록은

블록으로 구성

데이터파일은 여러 개의 블록으로 구성

논리구조(내부구조) 물리구조(외부구조)

블록(block)

• 가장 작은 구조

• 2kb, 4kb, 8kb…

• 1건 이상 데이터 보관

블록을 관리하기 위한 공간

비어있는 공간

1 choong CTO Seoul 한 건 분량의 데이터

익스텐트

• 연속된 블록의 집합

• 익스텐트 첫 위차와 블록의 개수만으로 데이터를 관리 가능

• 데이터를 한번에 읽어 올 수 있으므로 테이블의 풀스캔 성능을 향상

세그먼트

• 많은 데이터를 보관하기 위한 구조

• 익스텐트의 집합

• 테이블이나 인덱스가 포함

• 사용자 세그먼트외 데이터를 정렬 , 과거 데이터(언두)를 보관하는 세그먼트도 존재 (자동으로 생성)

테이블 스페이스

• 세그먼트를 분류해서 보관하기 위한 상자

• 한 개 이상의 데이터 파일로 구성

• DB를 관리 하기 위한 테이블 스페이스 및 사용자가 사용하는 테이블 스페이스가 존재(그외다수)

• 테이블 스페이스의 집합, 리두 로그 파일, 컨트롤 파일이 모이면 하나의 데이터베이스가 구성됨

블록안의 공간

• 데이터 입력 시 블록에 어느 정도의 공간을 남겨둠

• 데이터가 삭제 되어 블록안의 공간이 늘어나면 해당 블록으로 데이터를 채움

• 세그먼트에서 블록의 공간을 관리

ROWID

• 데이터행의 주소

• 데이터 파일의 번호나 데이터 파일안의 블록번호, 블록안에 행 번호와 같은 정보로 구성

대기와 락 대기

• 처리할 것이 없어서 쉬고있는 대기 (idle wait)

• 이유가 있어 어쩔 수 없이 하는 대기

• 이상상태로 발생하는 대기

idle이 아닌 대기

• I/O 대기 , 디스크에서 블록을 읽어오면서 발생하는 대기

• 디스크 장애

• 특정 사용자가 Lock을 걸어 놓고 자리를 비움…

• 대기 이벤트는 스태츠팩(or AWR) 이나 v$session_wait에서 볼 수 잇음

락에 의한 대기

• 락을 걸었다는 것 자체만으로 대기가 발생하지 않음, 락이 걸려 있는 대상에 다시 락을 걸 때 대기가 발생

• 락의 정보는 v$lock에서 확인

• HELD 컬럼에 REQUESTED가 보여지면 락을 요청하고(기다리고) 있는것.

데드락의 구조

• 고장나서 작동하지 않는 열쇠

• 서로 상대방이 보유하고 있는 락을 기다리느라 영원히 처리를 진행할 수 없는 상태

• ORA-00060(데드락) 일 때는 오라클에서 자동으로 한쪽의 처리가 rollback

래치(latch)의 구조

• 다중처리를 구현하기 위한 lock

• 오라클 내부에서 자동으로 얻어옴

• SQL을 한번 실행하기 위해 latch얻고 해제하기를 반복

• 메모리나 데이터를 조작할 때 상호 배타적 처리를 하지 않으면 데이터가 손상 될 수 있는 경우를 보호하고자 사용.

ACID

• A(Atomicity) : 원자성 • 트랜잭션에 포함되는 데이터 변경은 전부 OK나 전부 No

• C(Consistency) : 일관성 • 트랜잭션이 실행을 성공적으로 완료하면 언제나 일관성 있는 데이터

베이스 상태로 유지

• I(Isolation) : 고립성 • 트랜잭션끼리는 고립 되어 있으며 독립되어 있음

• D(Durability) : 지속성 • Commit한 트랜잭션은 장애가 발생하더라도 반드시 복구

리두와 언두

• 누군가가 무엇을 했다는 정보가 리두 로그

• 리두로그를 사용해서 과거의 데이터를 최신 데이터쪽으로 흐르게 하는것을 롤포워드

• 어떻게 하면 과거의 상태로 돌아갈 수 있는지 관한 정보가 언두 정보

• 언두의 정보를 사용해서 변경을 취소 하는 것을 rollback

리두 로그

• 데이터의 변경은 캐시위에서 이루어짐

• 데이터 변경 시 리두로그 생성 (아직 commit전)

리두 로그 아키텍쳐

서버 프로세스 리두 로그 버퍼 (공유 메모리)

LGWR 프로세스

1. 서버 프로세스가 리두 로그 버퍼에 리두 로그를 넣는다

2. LGWR은 서버 프로세스에 의뢰를 받거나 자발적으로 리두 로그를 리두로그 버퍼에서 리두로그 파일에 기록

리두 로그 파일

ARCH 프로세스 3. ARCH 프로세스가 아카이브 리두로그 파일에 옮긴다

파일 시스템에 저장할 수 있는 만큼 파일이 생성된다 * 리두 로그 파일은 매우 중요하므로 반드시 다중화

리두의 정리

• 병렬처리를 가능케 하고 높은 처리량을 실현 • 여러 개의 서버 프로세스는 동시에 데이터 변경이 가능.(같은 데

이터는 제외

• 응답을 중시 • Commit 할때 블록을 디스크에 기록 하지 않고, 리두 로그에 기록

하므로 빠른 커밋을 구현

• 커밋한 데이터는 지킨다 • 장애가 발생해서 디스크에 기록전이라도 리두로그와 데이터 파

일이 남아 있으므로 데이터 복구 가능

언두의 아키텍쳐

• 수동언두와 자동언두가 존재

• 데이터가 변경되면 언두 정보가 생성

• 언두정보는 세그먼트에 보관됨

• 언두 세그먼트는 링버퍼, 링버퍼는 조금 지나면 데이터가 덮이지만 commit하지 않은 데이터는 덮어써지지 않음, 만약 언두세크먼트가 가득차면 언두 세그먼트가 커짐

rollback 할때 동작

• rollback 이 수행되면 언두정보를 이용하여 데이터를 원래의 값으로 변경

• 비정상 종료시 PMON이 체크해서 뒤처리를 수행 하여 SMON이 트랜잭션 시작전 데이터로 변경

읽기 일관성

• 데이터를 검색 할때 어떤 시점의 데이터를 보여주는 기능

• 검색을 시작한 우에는 다른 세션에서 변경한 데이터를 읽지 못하게 하는것

• 언두를 사용함

커밋하지 않은 데이터를 읽어올 때

• 오라클에서는 기본적으로 트랜잭션간 고립성을 지키기 위해 read committed라고 불리는 동작을 함

• 다른 세션의 커밋한 변경 데이터는 읽을 수 있다

• 커밋되지 않은 변경 데이터는 읽어 오면 안되므로 언두를 사용해 과거의 정보를 가져옴