SQL 동작 원리
출처 : https://ssunws.tistory.com/44
- user process는 자신이 가져온 SQL문을 server process에 전달하기 위해 tnsnames.ora를 참고하여 서버를 찾아가 서버에서 작동하고 있는 listener에 접속 요청 (첫번째 연결에서만 listener 필요)
- listener가 서버에 요청하면 user process와 server process가 연결
- user process에서 server process에 SQL문 전달
- server process가 oracle server에 접속
select문 실행 원리
출처 : https://ssunws.tistory.com/44
DML 문장 실행원리(insert, update, delete, merge)
: select문과 같이 parse 과정까지는 동일 → execute (fetch과정은 없음)
execute 단계
-
redo log buffer에 변경 내역을 적음
-
undo segment에 변경전 데이터 기록
-
database buffer cache의 실제 데이터 변경
(redolog buffer : 데이터가 변경될 때 만약의 장애를 복구하기 위해 변경내역을 기록해두는 공간) -
redo log buffer에 기록하기 전 undo segment를 확보하고, commit되면 redo log buffer에 먼저 내려쓴 후 db에 씀
-
redo log buffer에는 DB내에서 데이터 변경이 생기는 모든 것들을 기록(select는 조회하는 문장이기 때문에 기록x)
트랙잭션이란 ?
: 하나의 논리적 작업 단위를 구성하는 일련의 연산들의 집합을 트랜잭션이라고 한다
EX - 트랜잭션의 예로 계좌 간의 자금 이체가 많이 언급된다. 한 계좌에서 10만 원을 인출하여 다른 계좌로 10만 원 입금하는 이체 작업은 전체 작업이 정상적으로 완료되거나, 만약 정상적으로 처리될 수 없는 경우에는 아무 것도 실행되지 않은 처음 상태로 되돌려져야 한다. 이러한 트랜잭션은 다양한 데이터 항목들을 액세스하고 갱신하는 프로그램 수행의 단위
트랜잭션의 성질
-
Atomicity(원자성)
: 트랜잭션의 모든 연산들이 정상적으로 수행 완료되거나 아니면 전혀 어떠한 연산도 수행되지 않은 상태를 보장해야 한다. atomicity는 쉽게 'all or nothing' 특성으로 설명된다. -
Consistency(일관성)
: 고립된 트랜잭션의 수행이 데이터베이스의 일관성을 보존해야 한다. 즉, 성공적으로 수행된 트랜잭션은 정당한 데이터들만을 데이터베이스에 반영해야 한다. 트랜잭션의 수행을 데이터베이스 상태 간의 전이(transition)로 봤을 때, 트랜잭션 수행 전후의 데이터베이스 상태는 각각 일관성이 보장되는 서로 다른 상태가 된다. 트랜잭션 수행이 보존해야 할 일관성은 기본 키, 외래 키 제약과 같은 명시적인 무결성 제약 조건들뿐만 아니라, 자금 이체 예에서 두 계좌 잔고의 합은 이체 전후가 같아야 한다는 사항과 같은 비명시적인 일관성 조건들도 있다. -
Isolation(독립성)
: 여러 트랜잭션이 동시에 수행되더라도 각각의 트랜잭션은 다른 트랜잭션의 수행에 영향을 받지 않고 독립적으로 수행되어야 한다. 즉, 한 트랜잭션의 중간 결과가 다른 트랜잭션에게는 숨겨져야 한다는 의미인데, 이러한 isolation 성질이 보장되지 않으면 트랜잭션이 원래 상태로 되돌아갈 수 없게 된다. Isolation 성질을 보장할 수 있는 가장 쉬운 방법은 모든 트랜잭션을 순차적으로 수행하는 것이다. 하지만 병렬적 수행의 장점을 얻기 위해서 DBMS는 병렬적으로 수행하면서도 일렬(serial) 수행과 같은 결과를 보장할 수 있는 방식을 제공하고 있다. -
Durability(지속성)
: 트랜잭션이 성공적으로 완료되어 커밋되고 나면, 해당 트랜잭션에 의한 모든 변경은 향후에 어떤 소프트웨어나 하드웨어 장애가 발생되더라도 보존되어야 한다.
트랙잭션 관리
병행 제어(Concurrency Control)
: 모듈여러 사용자나 여러 응용프로그램들이 동시에 수행되어도 서로 간섭하지 못하도록 보장하는 기법. 트랜잭션들이 동시에 수행되어도 각 트랜잭션이 고립적으로 수행된 것과 같은 결과를 보장한다.
-
직렬 스케줄(Serial Schedule)
:여러 트랜잭션들을 한 트랜잭션 씩 차례대로 수행 -
비직렬 스케줄(Non-serial Schedule)
:여러 트랜잭션들을 동시에 수행 -
직렬 가능(Serializable)하다
:비직렬 스케줄의 결과가 어떤 직렬 스케줄의 수행 결과와 동등하다.
병행 제어를 하지 않고 다수의 트랜잭션을 동시에 수행할 경우 발생하는 문제
-
Lost Update (갱신 손실)
:수행 중인 트랜잭션이 갱신한 내용을 다른 트랜잭션이 덮어 씀으로써 갱신이 무효가 되는 것 -
Dirty Read (더티 읽기)
: 완료되지 않은 트랜잭션이 갱신한 데이터
Unrepeatable Read (반복할 수 없는 읽기)
: 한 트랜잭션이 동일한 데이터를 두 번 읽을 때, 서로 다른 값을 읽는 것
로킹 -
독점 로크(X-lock, eXclusive lock)
: 한 데이터 항목에 대한 갱신은 한 트랜잭션에 대해서만 허용되므로, 트랜잭션에서 갱신을 목적으로 데이터 항목을 접근할 때는 독점 로크를 요청 -
공유 로크(S-lock, Shared lock)
:트랜잭션에서 읽을 목적으로 데이터 항목을 접근할 때는 공유 로크를 요청
(로킹 기법을 사용해도 로크를 너무 일찍 해제한다거나 하면 일관성이 깨질 수 있다.
따라서 "2단계 로킹 프로토콜(2-phase locking protocol)"를 거쳐 로크 요청과 해제가 이루어져야 한다.대부분의 로킹 관련 작업은 사용자가 신경 쓸 필요 없이, DBMS에서 모두 이루어진다.)
복구(Recovery)
: 모듈데이터베이스를 갱신하는 도중에 시스템이 고장나도 데이터베이스의 일관성이 유지되도록 하는 기법.
(여러 응용이 주기억장치 버퍼 내의 동일한 데이터베이스 항목을 갱신한 후에 디스크에 기록하는 것이, Disk I/O 작업을 줄일 수 있어 성능 향상에 도움이 된다. 즉 버퍼의 내용을 디스크에 기록하는 것을 최대한 줄이는 것이 일반적이다.)
- REDO
: 만일 고장이 발생하기 전에 트랜잭션이 완료 명령을 수행했다면, 복구 모듈은 이 트랜잭션의 갱신 사항을 REDO(재수행)하여 트랜잭션의 갱신이 지속성을 갖도록 해야 한다. - UNDO
: 고장이 발생하기 전에 트랜잭션이 완료 명령을 수행하지 못했다면, 원자성을 보장하기 위해 이 트랜잭션이 데이터베이스에 반영했을 가능성이 있는 갱신 사항을 UNDO(취소)해야 한다.
