DB 캐시 탐색 메커니즘

  • Direct Path I/O을 제외한 모든 블록 I/O는 메모리 버퍼캐시에 해당 블록이 있는지 확인하고 없으면 물리 I/O가 발생한다.

  • 인덱스 루트 블록을 읽을떄 , 인덱스 루트 블록을 통해 얻은 ROWID값으로 브랜치 블록을 읽을때 , 브랜치 블록에서 얻은 ROWID값으로 리프 블록을 읽을때 , 리프 블록에서 읽은 ROWID값으로 테이블 블록 읽을 때 , Full Scan시 모두 메모리 버퍼 캐시를 먼저 확인한다.

메모리 버퍼 캐시의 구조

  • 해시구조로 관리 , 해시 함수에 입력값을 넣어 나온 해시값으로 몇번 해시 Chain에 속해있는지 확인하고 , 해당 Chain에 연결되어 있는 버퍼 헤더를 순차 탐색한다. 결과값이 있다면 캐시된 버퍼 블록으로부터 데이터을 읽어오고 , 결과값이 없다면 물리 I/O가 발생하고 , 읽기 전에 버퍼 블록에 캐싱한다.

메모리 공유 자원에 대한 직렬화

  • 버퍼캐시는 SGA 구성요소로 프로세스간 공유 자원임. 즉 동시성이슈가 발생할 수 있어 동기화 작업이 필요함

  • Cache Buffer Chain Latch : 해시 체인에 접근하기전 프로세스는 Latch 를 획득해야만 접근이 가능하다. 만약 한 process가 Latch를 획득했다면 다른 process는 대기한다.

  • Buffer Lock : Buffer Block에 대한 동기화 메카니즘

Read more

Execution Plan 이란?

Execution Plan

  • 사용자가 실행한 sql을 어떤 방식으로 처리할 것인지에 대한 실행 계획으로 Optimizer에 의해 만들어짐.

  1. SQL 파싱과정을 통해 SQL에 문법적인 오류 없는지 검사
  2. 해당 SQL을 이전에 실행한 적이 있는지 SHARED POOL 메모리 검사. 만약 실행 기록이 있다면 그대로 실행 (SOFT PARSING)
  3. 만약 실행기록이 없다면 새로 실행 계획을 세운다. (HARD PARSING)

접근 경로 (Access Path)

(참조 : https://docs.oracle.com/database/121/TGSQL/tgsql_optop.htm#TGSQL228)

  • 실행 계획에서 Optimizer게 데이터를 읽을때 데이터를 접근하는 방식
  1. FULL TABLE SCAN : 테이블 전체 데이터를 읽어 조건에 맞는 데이터 추출
  2. ROWID SCAN : ROWID를 기준으로 데이터를 추출
  3. INDEX SCAN: 인덱스 사용하여 추출

무조건 TABLE SCAN 보다 INDEX SCAN이 우월한가?

  • 사용용도에 따라 다름. 배치 처리를 위해 전체 데이터를 읽어들여 통계자료 생성시에는 TABLE SCAN이 유리

INDEX SCAN의 종류

  1. INDEX UNIQUE SCAN : 한건이하의 ROWID를 반환하는 방식
  2. INDEX RANGE SCAN : 한건이상의 필요한 데이터가 포함된 일정범위의 인덱스 블록을 오름차순으로 접근
  3. INDEX SKIP SCAN
Read more

정규화 (Normalization)

정규화 이론의 목표

  • 가능한 데이터 중복성(Redundancy)를 제거해서 한가지 사실은 한 곳에서만 나타난다라는 원칙을 지키도록 한다.
  • 즉 정규화 과정(Normalization procedure)란 중복을 최소화하기 위해 데이터를 구조화 하는 작업이다.
  • 정규화 과정을 통해 특정 조건을 만족시키는 relation을 정규형이라고 한다. 제 1,2,3…정규형 등이 존재한다.

왜 정규화가 필요한가?

  • 정규화를 하지 않는 경우에 data redundancy로 인해 다음과 같은 이상현상들이 발생할 수 있다.
  1. insert annomaly (삼입 이상 ) : 특정 데이터를 삼입하고 싶은데, 자료가 부족해 삼입할 수 없다. 예를 들면 공급자,도시,부품이라는 attribute가 있다고 하면 공급자가 어떤 도시에 살고 있다는 정보는 부품이라는 정보가 있어야만 삼입할 수 있다.

  2. deletion annomaly (삭제 이상) : 하나의 정보를 삭제하고 싶지만, 필요한 정보까지 삭제될 수 있다. 위 예와 동일한데, tuple을 삭제할 경우에 공급자가 어떤 도시에 살고 있다는 정보가 소실될 수 있다.

  3. update annomaly (갱신 이상) : 데이터 갱신 중간 과정에 일부 data는 update된 상태, 일부 data는 original 상태로 inconsistent한 상태가 생길 수 있다.

정규형 만족 조건

  • 분해 집합은 무손실 조인, 무손실 분해 (nonloss decomposition)를 만족해야 한다.
  • 분해 집합은 함수적 종속성(functional dependency)을 보존해야 한다.

Nonloss Decomposition (무손실 분해) 이란?

  • non-loss decomposition : 특정 relation 을 다른 relation으로 분해하는 것으로 , 이 과정은 정보의 손실이 있어서는 안된다. 즉 가역적이여야 한다.
  • 가역적이란 말은 분해 이후 다시 table을 join 하였을떄 최초의 relation과 동일해야 한다는 말이다.

Functional Dependency (함수적 종속성) 이란?

  • 특정 relation 안에서 하나의 속성 집합에서 다른 속성으로의 다대일 (many-to-one)관계이다. 정확한 정의는 다음과 같다.
R을 relation이라 하고, X와 Y를 R의 속성 집합의 임의의 부분집합이라고 할때, Y가 X에게 함수적으로 종속되기 위한 필요 충분 조건은 다음과 같다. R에 있는 각각의 X의 값이 정확하게 하나의 Y의 값과 관련을 갖는 것이다.

이를 “X가 Y를 함수적으로 결정한다.” 또는 기호로는 X->Y 로 표시한다.

Read more

Transaction

Transaction

Transaction은 작업의 논리적인 단위로서 , 예를 들면 은행에서 출금 후 입금을 한다고 가정하였을떄 실제로 DB query문은 여러 번 나가겠지만 하나의 논리적인 작업 단위로 볼 수 있다.
Transaction이 필요한 이유는 데이터베이스 연산 중간에 일관되지 않은 상태가 존재하기 떄문이다. 2개의 연산중에 하나만 수행되고 하나는 아직 수행되지 않은 상태가 존재할 수도 있다.
따라서 데이터베이스는 작업의 완전성을 보장해주기 위해서 , 일련의 연산들을 사용자 입장에서 마치 단일 연산인것처럼 보이게 해준다.

추가로 transaction은 다음과 같은 특징을 갖는다.

  • Transaction은 recovery 단위이다. 실제로 DB에 쓰여지는 과정에서 system failure시 write ahead log (WAL) 라고 하는데 log라는 자료구조에 먼저 transaction을 쓰고나서 commit처리를 해준다. 즉 commit 이후에 system failure시에는 이 log를 보고 복구가 가능하다.
  • 아래에 Transaction 특성 중에 Isolation (독립성) 이 있다. 서로 다른 transaction은 독립적으로 수행될 수 있어야 하는데 , 이를 위해서는 concurrency control (동시성 제어) mechanism 이 필요하다.

Transaction의 특성 (ACID)

Transaciton 은 작업의 완전성을 보장하기 위해서 다음과 같은 4개의 특성을 갖는다.

  1. Atomicity (원자성): 원자성을 가지므로, 전부 실행되거나 (commit) 혹은 전부 실행되지 않는다 (rollback)
  2. Consistency(일관성) : Transaction은 데이터베이스의 일관성을 유지해야 한다. 즉 일관된 상태에서 일관된 상태로 변환해야 한다.
  3. Isolation(독립성): Transaction은 서로 독립적으로 수행될 수 있어야 한다.
  4. Durability(지속성) : Transaction이 commit되면 DB에 영구적으로 저장되야 한다.

Transaction 상태

transaction은 다음과 같은 상태를 가진다.

  • Active state : transaction이 아직 실행중인 상태
  • Partially committed state : transaction의 마지막 연산까지 전부 수행되었지만 commit 하기전의 상태
  • Failed : transaction중 오류가 발생해 중단된 상태
  • committed : transaction이 성공적으로 종료되어서 DB에 영구적으로 반영된 상태
  • aborted : transaction이 비정상적으로 종료되어서 rollback 연산을 통해서 작업을 취소하여 transaction 수행 이전의 일관된 DB 상태로 돌아간 상태

transaction의 병행수행 제어 기법 (concurrency control mechanism )

다른말로 동시성 제어인데, 여러가지 transaction 이 공유자원 (DB 데이터)를 동시에 접근할떄 여러가지 문제가 발생할 수 있다

대표적으로 다음과 같은 문제가 생길 수 있다

  • lost update problem(갱신 분실 문제) : transaction A 가 수행한 update가 transaction B가 수행한 update를 덮어씌움.
  • uncommitted dependency problem (비완료 의존성 문제) : transaction A 가 완료되지 않은 상태에서 갱신한 데이터를 transaction B 가 갱신했는데, transaction A가 rollback됨.
Read more

Index

Index 정의

Disk I/O를 최소화시키면서 원하는 데이터를 효율적으로 검색하기 위한 자료구조로 Data file과 분리된 index file 에 보관되며, 데이터 필드에 대한 탐색 키값과 record 물리적 위치를 가르키는 포인터로 구성된다.

  • Index의 크기는 data file에 비해 휠씬 작다.
  • 하나의 data file에 여러 개의 index가 정의될 수 있다. (하나의 희소인덱스와 여러개의 밀집 인덱스를 가질 수 있다. )
  • Index가 정의된 table의 필드를 탐색 키라고 한다.
Read more