☝️트랜젝션이란?

데이터베이스의 상태를 변경하는 작업의 단위.
※ ✏️ 작업의 단위라고 해서 하나를 뜻하는 것이 아니다.

✌️트랜젝션의 특징(ACID)

특징	설명
원자성(Atomicity)	모든 작업이 반영되거나 모두 롤백되는 특성
일관성(Consistency)	트랜잭션의 시작과 종료가 일관되어야 한다는 성질
독립성(Isolation)	여러 트랜잭션이 동시에 실행될 때, 각 트랜잭션이 다른 트랜잭션의 영향을 받지 않고 독립적으로 실행되는 것을 보장
영속성(Durability)	한 번 반영된 내용은 반영구적이어야 한다.

간단하게 표로 설명해 보았다. 자세히 풀어보면

• 원자성(Atomicity) : 트랜잭션 내의 모든 명령은 반드시 완벽히 수행되어야 하며 모두가 완벽히 수행되지 않고 어느 하나라도 오류가 발생하면 트랜잭션 전부가 취소되어야 한다.

• 일관성(Consistency) : 데이터베이스가 일관된 제약 조건, 규칙 및 관계를 유지

  🤔 예를 들자면, 중간에 트랜젝션이 완료되어 변경되어도 변경된 데이터를 사용하지 않고 시작된 값을 참조하여 사용한다.

• 독립성(Isolation) : 실제로 동시에 여러 개의 트랜잭션들이 수행될 때, 각 트랜잭션은 격리되어 있어 연속으로 실행된 것과 동일한 결과를 나타낸다.
  다시 말해, 다른 트랜잭션에 의해 영향을 받지 않게 하기 위해 고립을 시켜 수행한다는 의미이다.

• 영속성(Durability) : 트랜젝션이 성공적이라면 그 데이터는 반영구적이어야 함, 즉 로그를 남긴다고 할 수 있다. 만약 오류를 발생했다고 하더라도 오류 발생하기 전까지의 기록을 가지고 데이터를 반영구적으로 저장하고 있다고 볼 수 있다.
  
  

✌️트랜젝션의 상태

여기에서 트랜젝션이 시작되면 활성(Active) 상태가 된다.
당연히 트랜젝션이 시작되면 무조건 활성(Active) 상태라는 것은 아니다.
설계자가 정상적으로 연산이 되는 중일 때 활성(Active) 상태가 된다
그리고

• 성공하면 부분 완료(Partially Committed) 상태가 된다.
  그리고 설계자가 판단하여 Commit을 실행하면 DB의 변경된 내용을 모두 영구저장하고 트랜젝션이 종료된다. Commit이 완료된 상태를 완료(Committed)라고 한다.

• 오류라면 실패(Failed) 상태가 되어 트랜젝션은 연산을 중지한다. 그리고 Rollback으로 마지막으로 Commit지점 으로 돌아간다. 즉, 트랜젝션이 처음 시작했을 때의 시점으로 되돌아간다. Rollback이 수행된 상태를 철회(Aborted)라고 한다.

※
🤔 부분 완료(Partially Committed)란?
- ✏️ : 트랜젝션의 마지막 연산지점 & commit 바로 직전이다. 최종 commit을 기다리고 있는 상태이다. 이때 변경된 내용은 메모리에 임시로 저장되어 있다.


🤔 Commit이란? :
- ✏️ : 모든 작업을 정상으로 처리하겠다라는 의미이다. 커밋이 수행되면 하나의 트랜젝션 과정이 종료된다.


🤔 완료(Committed)란?
- ✏️ : Commit을 수행한 상태


🤔 실패(Failed)란?
- ✏️ : 작업이 오류/실패로 중단된 상태


🤔 Rollback이란?
- ✏️ : 작업 중 문제가 발생했을 때, 트랜젝션의 처리 과정에서 발생한 변경 사항을 취소하고, 트랜젝션 과정을 종료시킨다. 이전 COMMIT한 곳까지만 복구한다.


🤔 철회(Aborted)이란?
- ✏️ : 트랜젝션이 비정상적으로 종료되어 Rollback연산을 수행한 상태


🤔 중단(Abort)이란?
- ✏️ : 시스템 내부의 문제나 컴퓨터가 다운등으로 데이터베이스가 변경된 내용을 기록하지 못하면 실패(Failed)상태로 넘어간다.

---

☝️동시성제어 concurrency control(Serializability, Recoverability)

다음은 사전적인 설명이다.
직렬가능성 (Serializability) : 많은 컴퓨터 사용자가 동시에 한 데이터에 접근할 때 마치 혼자 그 데이터에 접근하는 것처럼 동일한 결과를 얻는 효과.
동시성 제어(concurrency control) : 복수의 처리 단위(트랜잭션)가 데이터 베이스의 내용을 동시에 갱신해도 데이터의 처음과 끝의 일관성을 잃지 않도록 제어하는 것.
복구 가능성(Recoverability) : 트랜잭션이 실패했을 때의 회복 가능성을 의미한다.

✌️Serializability(직렬가능성)

🤔 사전적인 설명을 읽어봐도 이해가 되지 않는다. 천천히 풀어서 이해를 해보자.

• 사용자가 동시에 한 데이터에 접근 = 동시에 트랜잭션이 한 데이터에 접근
• 혼자 데이터에 접근한 것처럼 = 다른 트랜잭션과 동시에 실행되어도 연산이 간섭없이 실행되는 것처럼 보이게 하는것

💡 그렇다는 건 트랜잭션의 특징 중 Isolation(독립성)과 같다는 게 아닐까?

✏️ 정리하자면 동시에 트랜잭션이 한 데이터에 접근할 때 마치 순차적인 것처럼 보이게하는 것이 Serializability(직렬가능성)라고 이해했다!
비슷한 개념인 Isolation(독립성)은 트랜잭션 간의 상호작용을 중점을 두고 Serializability(직렬가능성)는 트랜잭션의 병행 실행 결과를 보장을 중점을 두고 있다.

✌️Schedule

🤔 스케줄(Schedule)이 뭘까?

✏️ 간단하게 설명하자면 스케줄이 동시에 실행될 때 간섭하여 실행될 수 있는 모든 경우의 수라고 보면 된다.

💡 좀 더 사전적으로 풀어보면 스케줄(Schedule)은 동시에 실행될 때 그 트랜잭션들에 속한 operation들의 실행 순서를 의미한다. 내부의 operation이 겹쳐서 실행될 때 어떻게 실행되냐에 따라 실행결과가 다르게 나타날 수 있기때문에 DBMS는 non-serial schedule serial schedule으로 나뉜다.

- non-serial schedule

✏️ Interleave 실행기법을 통해 트랜잭션 내부 연산이 번갈아가면서 병렬로 실행되는 스케줄 기법을 의미한다. 그리고 성능이 좋다!👍
하지만 순서가 바뀌어 의도한 결과가 나오지 않을 수 있다.

- serial schedule

✏️ non-serial schedule와 정확히 반대의 성질이다. 순차적으로 진행되기 때문에 순서와 정합성이 보장되는 것이다. 하지만 성능이 많이 떨어진다.

- serializability scedule

🤔Serializability(직렬가능성)? 순차적으로 보이게 하는 것? scedule? 모든 경우의 수? 어떤 뜻인지 살펴보자.

✏️ 위의 두 가지 경우를 해결하기 위한 기법으로 non-serial schedule하고 serial schedule을 사용하여 빠르고 정합성이 보장되는 방법이다. conflict serializable, serial schedule, conflict equivalent 라고 표현하기도 한다.

🤔 conflict(갈등)란?
- 두 개의 operation이 충돌하는 것을 의미한다. 여기서 충돌은 아래 세가지 조건을 충족하면 충돌이라고 한다.
1. 두 operation이 서로 다른 transaction에 속해 있다
2. 두 operation이 같은 데이터에 접근한다
3. 두 operation 중에 적어도 하나는 데이터를 쓴다(write)


🤔Conflict equivalent란?
- 두 개의 schedule에 대해서 사용될 수 있는 개념이다. 두 개의 schedule이 아래의 두 가지 조건을 만족하면 '두 schedule은 conflict equivalent하다'라고 말할 수 있다
1. 두 schedule은 같은 transaction들을 가진다
2. 어떤(any) conflict operations의 순서도 양쪽 schedule이 모두 동일하다

- conflict serializable

어느 한 schedule이 serial schedule과 conflict equivalent하다면, '이 schedule은 conflict serializable하다'라고 말할 수 있다

다르게 표현하자면,

두 개의 schedule이 conflict equivalent 할 때, 한 schedule이 erial schedule이라면, '다른 한 schedule은 conflict serializable하다'라고 말할 수 있다
이거는 쉬운코딩 블로그를 참조해서 작성하자 예제를 들고오자

✌️Recoverability(복구 가능성)

트랜잭션 실행 중에 발생하는 시스템 오류, 손상된 디스크 블록, 장애, 전원 손실 또는 다른 비정상적인 상황으로부터 데이터베이스를 회복하는 능력을 말한다. 이를 통해 데이터베이스는 일관된 상태를 유지하고, 시스템 장애가 발생해도 데이터 손실을 최소화할 수 있다.

대부분의 데이터베이스 시스템에서 제공되는 핵심 기능으로, 트랜잭션의 일관성과 내구성을 보장하기 위해 필요하다.

recoverable한 스케줄은 무엇이 있을까?

- irrecoverable schedule

🤔 irrecoverable schedule이란?
: 커밋되지 않은 트랜잭션의 변경 내용을 다른 트랜잭션이 읽어들일 수 있는 상황을 가리킨다.

- Unrecoverable Schedule

🤔 Unrecoverable Schedule이란?
: 어떤 트랜잭션의 변경 내용이 다른 트랜잭션에 의해 읽히고 커밋되기 전에 롤백되는 상황을 가리킨다.

🤔 둘 다 비슷해 보이는데 뭐가 다른 걸까?
: 일단 공통점은 데이터베이스 시스템에서 복구할 수 없는 상태라는 거다.

✏️
Unrecoverable schedule은 dirty read와 관계있다. 한 트랜잭션이 데이터를 변경한 후에 커밋되지 않은 상태에서 다른 트랜잭션이 해당 변경된 데이터를 읽는 경우를 나타낸다.
✏️
irrecoverable schedule은 한 트랜잭션이 데이터를 변경한 후에 다른 트랜잭션이 해당 변경된 데이터를 읽고, 그 후에 변경 트랜잭션이 롤백되어 변경 내용이 취소되는 경우이다.


💡 Unrecoverable Schedule은 dirty read와 관련이 있고, irrecoverable schedule은 Rollback과 관련이 있구나!


🤔 그럼 dirty read는 뭔데?
✏️ GPT : 트랜잭션에서 다른 트랜잭션이 아직 커밋되지 않은 데이터를 읽는 현상을 가리킵니다. 즉, 한 트랜잭션이 어떤 데이터를 변경하고 아직 커밋되지 않은 상태에서 다른 트랜잭션이 해당 데이터를 읽는 것

- recoverable schedule

🤔 recoverable schedule란?
: 트랜잭션은 자신이 읽고있는 데이터를 write한 트랜잭션들이 모두 커밋, 롤백 되기 전까지 커밋하지 않는 스케줄을 의미
✏️ 그러면 트랜잭션이 기다리고있는데 너무 비용이 크다고 생각한다면 그게 💡cascading rollback이라고 한다! 그리고 이를 방지하는게 아래에 나온 cascadeless schedule이다!

cascadeless schedule

🤔 recoverable schedule란?
: 한 트랜잭션이 다른 트랜잭션이 바꾼 데이터를 읽지 않게 한다.
즉, 커밋 혹은 롤백된 뒤에만 데이터를 읽을 수 있는 스케줄을 의미한다.
이렇게 하면 트랜잭션끼리 서로 영향을 주고 받지 않아서 데이터 일관성이 유지되고 병행 처리 문제를 피할 수 있다.

- strict scedule

🤔 strict scedule란?
cascadeless schedule 보다 강력한 규칙으로 commit하지 않으면write한 데이터는 읽지도 쓰지도 않는다.
커밋 혹은 롤백된 뒤에만 데이터를 읽을 수 있는 스케줄을 의미한다.

✌️concurrency control(동시성제어)

데이터베이스 시스템에서 동시에 실행되는 여러 트랜잭션 간의 상호작용을 조절하여 데이터 일관성과 무결성을 유지하는 기술 데이터베이스에서 여러 트랜잭션이 동시에 실행될 때, 이들 간의 상호작용은 데이터베이스의 일관성을 해치는 여러 문제를 발생시킬 수 있습니다. 따라서 데이터베이스 시스템은 병행 제어를 통해 이러한 문제를 해결하고 데이터베이스의 무결성을 보장합니다.
행 제어의 목표는 다음과 같습니다:

동시성 제어: 병행 제어는 여러 트랜잭션이 동시에 실행될 때 일어날 수 있는 다양한 문제를 방지합니다. 예를 들어, 더티 리드, 반복 불가능한 읽기, 파악적 읽기 등의 문제를 방지하여 데이터의 일관성을 유지합니다.

일관성 유지: 병행 제어는 트랜잭션의 동시 실행으로 인해 발생할 수 있는 데이터의 비일관성을 방지합니다. 모든 트랜잭션이 일관된 데이터를 읽고 쓰도록 보장하여 데이터베이스의 일관성을 유지합니다.

교착 상태 방지: 병행 제어는 교착 상태(deadlock)를 방지합니다. 교착 상태는 두 개 이상의 트랜잭션이 서로 대기하면서 무한 대기 상태에 빠지는 문제를 말합니다. 병행 제어 기법은 이러한 상황을 사전에 예방하거나 교착 상태가 발생했을 때 이를 해결하기 위한 방법을 제공합니다.

성능 향상: 병행 제어는 동시에 여러 트랜잭션을 실행함으로써 시스템의 성능을 향상시킵니다. 효율적인 병행 제어 알고리즘을 사용하면 데이터베이스의 처리량을 증가시키고 응답 시간을 단축할 수 있습니다.

주요한 병행 제어 기법으로는 락(Locking), 타임스탬프(Timestamp) 기반 스케줄링, 다중 버전 동시성 제어(MVCC) 등이 있습니다. 이러한 기법들은 데이터베이스 시스템이 트랜잭션을 효율적으로 관리하고 병행성을 유지하는 데 도움이 됩니다.
🤔미완성
✏️
💡

---

☝️격리수준과 이상현상

✌️격리수준

🤔 격리수준 이란?
: 트랜잭션끼리 얼마나 서로 고립되어 있는지를 나타내는 수준

즉, 한 트랜잭션이 다른 트랜잭션이 변경한 데이터에 대한 접근 강도를 의미
레벨이 높아질수록 트랜잭션간 고립정도가 높아지며, 성능저하도 야기됩니다.

일반적인 온라인 서비스에서는 READ COMMITTED나 REPEATABLE READ 중 하나를 사용합니다.

격리수준은 트랜잭션의 ACID 특성을 보장하기 위해서 사용합니다.

Locking을 통해 이를 해결할 수 있지만, 무조건적인 Locking은 성능저하를 가져옵니다.

반대로 느슨한 Locking은 데이터 무결성에 큰 문제를 가져옵니다.

효율적인 Locking의 사용을 위해 적절한 격리수준은 반드시 필요합니다.

✏️ 격리수준은 트랜잭션 ACID특성을 보장하기 위해서 사용한다. Locking이라는걸 통해 해결이 가능하지만 무조건적으로 사용하면 join처럼 성능 저하가 생긴다. 반대로 느슨하게 사용하면 데이터 무결성에 문제가 생긴다. 그러니 적절하게 격리수준을 사용해야한다.
💡 격리수준 = Locking

🤔 Non-repeatable Read이란?
: 한 트랜잭션에서 다른 트랜잭션이 커밋(Commit)한 데이터를 같은 쿼리로 2번이상 조회했을 때 그 결과가 상이한 상황.
보통 데이터의 수정/삭제가 발생했을 경우 발생합니다.


🤔 Phantom Read이란?
:다른 트랜잭션이 커밋(Commit)한 데이터가 있더라도 자신의 트랜잭션에서 읽었던 내용만 사용하는 것을 의미.
즉, 한 트랜잭션에서 같은 쿼리를 2번이상 조회했을 때 없던 결과가 조회되는 상황.
보통 데이터의 삽입이 발생했을 경우 발생합니다.

- Read Uncommitted (Level 0)

떤 트랜잭션의 내용이 커밋(Commit)이나 롤백(Rollback)과 상관없이 다른 트랜잭션에서 조회가 가능
Dirty Read가 발생할 수 있다.

- Read Committed (Level 1)

한 트랜잭션의 변경내용이 커밋(Commit)되어야만 다른 트랜잭션에서 조회가 가능합니다. 대부분의 RDBMS에서 기본적으로 사용하는 격리수준
REPEATABLE READ의 정합성에 어긋납니다. 즉, Non-repeatable Read이 발생

- Repeatable Read (Level 2)

트랜잭션이 시작되기 전에 커밋된 내용에 대해서만 조회가 가능합니다. MySQL에서 기본으로 사용하며, 이 격리수준에서는 Non-repeatable Read이 발생하지 않습니다.
랜잭션이 시작 시점 데이터의 일관성을 보장해야 하기 때문에 트랜잭션의 실행시간이 길어질수록 계속 멀티 버전을 관리해야 하는 단점이 발생합니다.

하지만 Phantom Read가 발생할 수 있습니다.

- SERIALIZABLE (Level 3)

가장 단순하면서 엄격한 격리 수준이지만 성능 측면에서는 동시 처리성능이 가장 낮습니다. SERIALIZABLE에서는 PHANTOM READ가 발생하지 않습니다.

트랜잭션들이 동시에 일어나지 않고, 순차적으로 실행되는 것처럼 동작합니다.

하지만, 거의 사용되지 않습니다.

✌️이상현상

이부분은 정규화에서 작성하였다 참고바란다.
데이터베이스 - 정규화

---

출처:
https://github.com/devSquad-study/2023-CS-Study/blob/main/DB/db_transaction_concurrency-control.md


https://velog.io/@j_user0719/DB-Serializability-%EC%99%80-Recoverable#recoverable-schedule


https://akasai.space/db/about_isolation/


https://easy-code-yo.tistory.com/25


https://akasai.space/db/about_lock/


https://dev-coco.tistory.com/63