1. SQL 처리 과정과 I/O

1. SQL 파싱과 최적화
2. SQL 공유 및 재사용
3. 데이터 저장 구조 및 I/O 메커니즘

---

라이브러리 캐시에 없는 SQL 실행 = 하드 파싱 = 내부 프로시저를 만드는 과정

1) 옵티마이저가 최적화

2) 로우 소스 생성

모든 SQL을 소프트 파싱하기 어려운 이유

-> 이름 없는 SQL 문제

-> 바인드 변수의 중요성

-> 하드 파싱을 최소화하기 위함

 

SQL이 느린 이유와 DBMS가 이를 극복하는 방법

CPU는 동시에 하나의 작업만 수행하므로

느린 디스크 I/O 시간 동안 프로세스가 기다리기 때문에

-> I/O 병목이 발생하므로 SQL이 느리게 된다.

-> 디스크 I/O를 최소화 하는 방법이 필요

-> 이를 위해 설계된 데이터베이스의 저장 구조

 

데이터베이스 저장 구조

테이블 스페이스 -> 여러 세그먼트 -> 확장가능한 익스텐트

-> 하나의 익스텐트는 연속된 블록의 집합 -> 한 블록은 하나의 테이블에서만 접근 가능

 

익스텐트 단위로 공간을 확장하지만, 레코드는 실제로 데이터 블록에 저장

-> 블록은 연속되어 저장되기 때문에 첫째 블록의 위치(DBA)를 저장

-> 세그멘트 헤더에서 익스텐트목록을 맵으로 관리

 

 

블록 단위 I/O

1) 시퀀셜 엑세스

: 인덱스 스캔은 리프 블록의 주소값을 통해, 테이블 스캔은 익스텐트 맵을 통해 스캔 (Table Full Scan)

(DBA_EXTENTS로 확인)

2) 랜덤 액세스

: 레코드를 한블록씩 접근 

 

SQL 튜닝의 필요성

버퍼캐시 히트율 공식

-> 버퍼캐시 히트율 (BCHR) 공식으로 알 수 있는 것은 논리적 I/O를 줄임으로써 궁극적으로 물리적 I/O를 줄인다는 것

(BCHR이 성능을 좌우하지만, BCHR이 높다고 반드시 SQL 성능이 높은 건 아니다.)

 

물리적 I/O는 통제 불가능한 외생 변수 -> 논리적 I/O를 줄이는 방법 -> SQL 튜닝 -> 접근할 블록 개수 최소화

(혹은 DB 버퍼 캐시를 늘리는 방법 -> 물리적 스케일업은 한계가 존재)

 

 

인덱스 구조

1. 루트 블록 (Root Block)
   - 인덱스 트리의 최상위 블록입니다.
   - 모든 인덱스 브랜치의 시작점입니다.
   - 이 블록은 다른 블록들을 가리키는 포인터를 포함하고 있습니다.

2. 브랜치 블록 (Branch Block)
   - 루트 블록 이외의 최상위 블록들입니다.
   - 리프 블록에 이르는 경로를 지정합니다.
   - 각 브랜치 블록에는 키 값 범위와 해당 범위에 속하는 다음 수준의 블록을 가리키는 포인터가 포함됩니다.

3. 리프 블록 (Leaf Block)
   - 인덱스의 가장 하위 레벨에 위치한 블록입니다.
   - 실제 데이터 레코드 또는 데이터 행의 포인터를 가지고 있습니다.
   - 데이터베이스에서 실제 검색이 발생하는 위치입니다.

4. 헤더 블록 (Header Block)
   - 인덱스 파일의 시작 부분에 위치한 블록으로, 인덱스에 대한 메타데이터를 저장합니다.
   - 인덱스의 구조 및 특성과 관련된 정보를 포함합니다.

5. 공백 블록 (Empty Block)
   - 인덱스에 삽입된 후에 삭제되거나 비어 있는 블록입니다.
   - 삭제된 레코드에 대한 공간 재활용을 위해 유지됩니다.

 

Single Block I/O (주로 인덱스 이용)
Multi Block I/O   (다량의 데이터 블록 접근)

Single Block I/O(1,2,3)과 Multi Block I/O(4,5,6,7)

Multi Block I/O는 인접한 블록을 캐시에 미리 적재 -> Multi Block I/O 단위가 성능에 영향

-> db_file_multiblock_read_count

 

 

Table Full Scan (테이블의 모든 블록을 읽는 방식)
Index Range Scan (인덱스를 통해 스캔한 ROWID로 레코드를 읽는 방식)

Table Full Scan이 항상 나쁜 건 아니다. -> 오히려 불필요한 인덱스가 성능을 떨어뜨리는 경우도 존재

-> 집계용 SQL, 배치 프로그램에서는 Table Full Scan이 더 나은 경우가 많다.

	Table Full Scan	Index Range Scan
방식	시퀀셜 액세스, Multi Block I/O	랜덤 액세스, Single Block I/O
과정	1. 블록의 모든 레코드 읽기 2. 한 번의 물리적 I/O로 인접한 블록 모두 접근	캐시에 없는 레코드마다 물리적 I/O 수행
접근 방법	각 블록에 대해서 단 한 번만 접근	접근한 테이블에 반복 접근 가능(N개의 레코드에 대해서 최대 N번) -> 큰 테이블에서 소량 데이터 접근 시 사용

 

 

카디널리티 (해당 열이나 관계에서 고유한 값의 개수)

1. 카디널리티 추정
   - 데이터베이스에 열(column)의 카디널리티를 추정할 때 사용됩니다.
   - 일반적으로 데이터의 샘플을 사용하여 전체 데이터셋에 대한 카디널리티를 추정합니다.
   - 예를 들어, 열에서 고유한 값의 비율을 측정하여 전체 행 수에 곱해 전체 고유한 값의 개수를 추정할 수 있습니다.

2. 인덱스 선택
   - 쿼리의 성능을 최적화하기 위해 인덱스를 선택할 때 카디널리티 정보를 사용합니다.
   - 인덱스를 선택할 때 카디널리티가 높은 열을 우선적으로 선택하는 것이 일반적입니다. 이는 인덱스를 사용하여 더 정확하고 효율적인 검색을 수행할 수 있기 때문입니다.

3. 조인 순서 결정
   - 조인 연산을 수행할 때 카디널리티 정보를 사용하여 조인 순서를 결정하는 데 도움이 됩니다.
   - 카디널리티가 높은 열을 먼저 조인하면 중간 결과 집합의 크기를 줄일 수 있으므로 성능을 향상시킬 수 있습니다.

4. 쿼리 최적화
   - 쿼리 실행 계획을 최적화할 때 카디널리티 정보를 사용하여 적절한 인덱스를 선택하거나 조인 순서를 결정하는 데 활용됩니다.
   - 카디널리티를 고려하여 쿼리 실행 계획을 구성하면 쿼리의 실행 속도를 향상시킬 수 있습니다.

 

 

캐시 알고리즘 (캐시에서 데이터를 어떻게 관리할지 결정)
캐시 탐색 알고리즘 (캐시에서 데이터를 찾는 방법을 결정)

1. 캐시 알고리즘 (Cache Replacement Algorithm)
   - 캐시 알고리즘은 캐시에 데이터를 어떻게 저장하고 관리할지 결정하는 알고리즘입니다.
   - 주로 가장 오랫동안 사용되지 않은 데이터를 제거하는 LRU (Least Recently Used)
      가장 적게 액세스된 데이터를 제거하는 LFU (Least Frequently Used)
      먼저 들어온 데이터를 제거하는 FIFO (First-In, First-Out) 등의 알고리즘이 사용됩니다.
   - 이 알고리즘은 캐시에서 데이터를 제거하거나 교체하는 방식을 제어합니다.

2. 캐시 탐색 알고리즘 (Cache Lookup Algorithm)
   - 캐시 탐색 알고리즘은 캐시에서 데이터를 찾는 방법을 결정하는 알고리즘입니다.
   - 주로 캐시에 저장된 데이터를 검색할 때 사용되는 방법을 지정합니다.
   - 대표적인 캐시 탐색 알고리즘에는 직접 매핑(Direct Mapping), 전체 연관(Fully Associative), 집합 연관(Set Associative)
   - 이 알고리즘은 캐시에서 특정 데이터를 찾는 데 걸리는 시간과 효율성을 결정합니다.

 

버퍼캐시 탐색 과정 (버퍼 캐시에서 블록을 찾는 과정)

캐시 탐색 알고리즘

1. 해시 알고리즘을 통해 버퍼 헤더 탐색
2. 버퍼 헤더에서 포인터를 읽어서 버퍼 블록 엑세스

공유자원 동시성 제어를 위한 버퍼캐시 직렬화

동시에 접근 시 발생하는 블록 정합성 문제를 방지하기 위해 순차적 접근하는 방법

-> Letch

 

캐시버퍼 체인 레치 / 버퍼블록 직렬화 메커니즘 (버퍼 락)

버퍼 캐시 히트율(BCHR)를 높여야하지만, 래치에 의한 경합이 발생하면 캐시 I/O 속도 느려짐

(SGA를 구성하는 서브 캐시마다 별도의 래치가 존재하므로)

-> 캐시 경합을 줄이기 위해 논리적 I/O를 줄여야함

---

+) 운영체제

공유 메모리 제어

세마포어(Semaphore), 뮤텍스(Mutex), 레치(Latch), 락(Lock)은 모두 공유 자원에 대한 접근을 제어하는 동기화 메커니즘입니다. 각각의 개념을 자세히 비교하고, 운영 체제에서 공유 메모리를 제어하는 방법도 설명하겠습니다.

1. 세마포어(Semaphore)
   - 세마포어는 공유 자원에 대한 접근을 제어하기 위한 동기화 도구입니다.
   - 이진 세마포어는 0 또는 1의 값을 가지며, 뮤텍스와 유사하게 단일 스레드에게만 접근을 허용합니다.
   - 카운팅 세마포어는 임의의 양의 값을 가질 수 있으며, 한 번에 여러 스레드에게 접근을 허용하는 허용된 수를 제어합니다.
   - 프로세스 또는 스레드가 세마포어를 획득하면 해당 세마포어의 값이 조절되며, 릴리즈할 때 값이 복구됩니다.

2. 뮤텍스(Mutex)
   - 뮤텍스는 상호 배제를 위한 동기화 도구입니다.
   - 뮤텍스는 이진 세마포어와 유사하게 사용되며, 공유 자원에 대한 배타적 접근을 제공합니다.
   - 한 번에 하나의 스레드만 뮤텍스를 보유할 수 있으며, 다른 스레드가 뮤텍스를 획득하기 위해서는 현재 보유중인 스레드가 뮤텍스를 릴리즈해야 합니다.

3. 레치(Latch)
   - 레치는 주로 데이터베이스 시스템에서 사용되는 동기화 메커니즘으로, 공유 메모리 자원에 대한 접근을 제어합니다.
   - 레치는 주로 공유 메모리 자원에 대한 읽기와 쓰기를 제어하는 데 사용됩니다.
   - 공유 레치는 여러 스레드가 동시에 읽기 작업을 수행할 수 있도록 하며, 배타 레치는 쓰기 작업을 위해 한 번에 하나의 스레드만 접근할 수 있도록 합니다.

4. 락(Lock)
   - 락은 공유 자원에 대한 접근을 제어하는 동기화 도구입니다. 데이터베이스에서는 주로 트랜잭션 간에 공유 자원에 대한 접근을 제어하기 위해 사용됩니다.
   - 락은 배타적 락과 공유 락으로 구분됩니다. 배타적 락은 하나의 스레드만 자원을 변경할 수 있도록 합니다. 공유 락은 여러 스레드가 자원을 읽을 수 있도록 합니다.

운영 체제에서는 세마포어, 뮤텍스 등의 동기화 메커니즘을 사용하여 공유 메모리에 대한 접근을 제어합니다. 프로세스나 스레드 간에 공유되는 메모리에 대한 접근은 동기화 메커니즘을 사용하여 상호 배제를 보장합니다. 이를 통해 데이터 일관성을 유지하고 경쟁 조건을 방지합니다. 예를 들어, 세마포어를 사용하여 공유 메모리에 대한 접근을 제어하고, 뮤텍스를 사용하여 임계 영역을 보호할 수 있습니다.

 

트랜잭션

트랜잭션(Transaction)은 데이터베이스에서 수행되는 논리적인 작업의 단위를 나타냅니다. 트랜잭션은 데이터베이스에서 데이터를 읽거나 쓰는 등의 작업을 원자적(Atomic), 일관적(Consistent), 고립된(Isolated), 영속적(Durable)으로 수행하는 논리적인 단위입니다. 이를 ACID 속성이라고도 합니다.

1. 원자성(Atomicity)
   - 트랜잭션은 한 번에 하나의 논리적인 작업 단위로 간주됩니다. 이는 트랜잭션 내의 모든 작업이 성공하거나 실패할 때까지 모두 적용되거나 모두 롤백되는 것을 의미합니다. 따라서 트랜잭션 내의 모든 작업은 원자적인 단위로 처리됩니다.

2. 일관성(Consistency)
   - 트랜잭션이 실행된 후에는 데이터베이스가 일관된 상태를 유지해야 합니다. 즉, 트랜잭션의 실행 전후에 데이터베이스의 무결성 제약 조건이 만족되어야 합니다. 예를 들어, 계좌 이체 트랜잭션에서는 송금과 수신 쪽의 잔액 합계가 일치해야 합니다.

3. 고립성(Isolation)
   - 고립성은 한 트랜잭션이 실행되는 동안 다른 트랜잭션의 작업에 영향을 받지 않아야 함을 의미합니다. 다시 말해, 한 트랜잭션이 실행 중일 때 해당 데이터에 대한 다른 트랜잭션의 접근을 막는 격리 수준이 보장되어야 합니다.

4. 영속성(Durability)
   - 트랜잭션이 성공적으로 완료되면 그 결과가 영구적으로 유지되어야 합니다. 즉, 데이터베이스 시스템의 장애가 발생하더라도 커밋된 트랜잭션의 결과는 보존되어야 합니다.

트랜잭션은 일련의 데이터베이스 작업을 논리적으로 묶어서 원자적으로 처리하는데, 이를 통해 데이터베이스의 무결성과 일관성을 보장하고 데이터베이스 시스템의 신뢰성을 유지합니다. 따라서 트랜잭션은 데이터베이스 시스템에서 매우 중요한 개념입니다.

 

트랜잭션과 락의 관계

 

트랜잭션(Transaction)과 락(Lock)은 데이터베이스에서 동시성 제어와 관련이 깊은 개념입니다. 여러 개의 트랜잭션이 동시에 데이터베이스에 접근하여 데이터를 읽거나 쓸 때 발생할 수 있는 문제를 해결하기 위해 락이 사용됩니다. 이러한 관계를 더 자세히 설명하겠습니다.

1. 트랜잭션의 동시성 제어
   - 트랜잭션이 동시에 실행될 때 발생할 수 있는 문제 중 하나는 일관성이 깨질 수 있다는 것입니다. 여러 트랜잭션이 동일한 데이터를 동시에 변경하거나 읽을 경우, 데이터베이스의 일관성이 깨질 수 있습니다.
   - 이러한 문제를 해결하기 위해 트랜잭션은 데이터에 대한 접근을 제어해야 합니다. 다른 트랜잭션이 데이터를 읽거나 쓰는 동안 해당 데이터에 대한 다른 트랜잭션의 접근을 막아야 합니다.

2. 락을 이용한 동시성 제어
   - 락은 데이터베이스에서 동시에 여러 트랜잭션이 접근하는 것을 제어하는 데 사용됩니다. 트랜잭션은 데이터에 접근하기 전에 해당 데이터에 대한 락을 요청하고, 데이터를 사용한 후에는 락을 해제합니다.
   - 읽기 락(Read Lock)은 다른 트랜잭션에 의한 동시적인 데이터 변경을 막기 위해 사용됩니다. 하나의 트랜잭션이 읽기 락을 획득하면 다른 트랜잭션은 해당 데이터에 대한 쓰기 락을 요청할 수 없습니다.
   - 쓰기 락(Write Lock)은 트랜잭션이 데이터를 변경하는 경우 사용됩니다. 쓰기 락을 획득한 트랜잭션은 다른 트랜잭션이 해당 데이터를 읽거나 쓸 수 없습니다.

3. 트랜잭션과 락의 관계
   - 트랜잭션은 데이터베이스에서 일관성을 유지하기 위해 락을 사용하여 데이터에 접근을 제어합니다. 트랜잭션은 데이터를 읽거나 쓸 때 해당 데이터에 대한 적절한 락을 요청하고, 작업을 완료한 후에는 락을 해제합니다.
   - 따라서 트랜잭션과 락은 데이터베이스에서 데이터의 일관성과 동시성을 보장하기 위해 밀접하게 연관된 개념입니다. 트랜잭션은 데이터를 락을 사용하여 제어하고, 락은 트랜잭션이 데이터에 안전하게 접근할 수 있도록 보장합니다.

 

 

트랜잭션 격리 수준

트랜잭션 격리 수준(Transaction Isolation Level)은 동시에 여러 트랜잭션이 동시에 데이터베이스에 접근할 때 발생하는 문제를 해결하기 위해 정의된 개념입니다. 격리 수준은 트랜잭션 간에 데이터 접근과 변경이 어떻게 격리되는지를 결정합니다. 데이터베이스 시스템은 보통 다음과 같은 네 가지의 격리 수준을 제공합니다:

1. Read Uncommitted (미커밋된 읽기)
   - 이 격리 수준에서는 한 트랜잭션이 아직 커밋되지 않은 다른 트랜잭션의 변경 사항을 읽을 수 있습니다. 이는 다른 트랜잭션의 변경 내용이 반영되기 전에 데이터를 읽을 수 있다는 것을 의미합니다. 이것은 가장 낮은 격리 수준이며, 일관성이 전혀 보장되지 않습니다.

2. Read Committed (커밋된 읽기)
   - 이 격리 수준에서는 트랜잭션이 커밋된 데이터만 읽을 수 있습니다. 따라서 다른 트랜잭션이 아직 커밋되지 않은 변경 사항을 보지 않습니다. 이는 트랜잭션 간에 일부 일관성이 유지되지만, 동일한 쿼리 내에서도 일관성이 보장되지 않을 수 있습니다.

3. Repeatable Read (반복 가능한 읽기)
   - 이 격리 수준에서는 트랜잭션이 읽은 데이터가 다른 트랜잭션에 의해 변경되지 않음을 보장합니다. 따라서 동일한 쿼리를 반복 실행해도 같은 결과를 얻을 수 있습니다. 이는 읽기 동안의 일관성을 보장하지만, 범위 락(Range Lock)을 사용하여 다른 트랜잭션이 해당 범위의 데이터를 변경하지 못하도록 보장합니다.

4. Serializable (직렬화 가능한)
   - 이 격리 수준은 가장 높은 수준의 격리를 제공합니다. 동시에 실행되는 트랜잭션 간에 데이터베이스가 일관성을 유지하면서도 각 트랜잭션의 결과가 마치 순차적으로 실행되는 것처럼 보이도록 보장합니다. 이는 트랜잭션 간에 격리를 완벽하게 보장하지만, 동시성이 낮아질 수 있습니다.

트랜잭션 격리 수준은 다른 트랜잭션과의 상호작용에 대한 제어 수준을 나타냅니다. 더 높은 격리 수준은 일반적으로 데이터 일관성을 보다 잘 보장하지만, 동시성에 대한 성능 저하를 유발할 수 있습니다. 선택할 격리 수준은 데이터베이스의 요구 사항과 트랜잭션 처리의 필요성에 따라 달라집니다.

 

경쟁 상태와 고착 상태

1. 경쟁 조건 (Race Condition)
   - 경쟁 조건은 둘 이상의 프로세스나 스레드가 공유된 자원에 동시에 접근하려고 할 때 발생하는 현상입니다.
   - 이러한 상황에서는 실행 순서에 따라 결과가 달라질 수 있습니다. 즉, 한 프로세스나 스레드가 공유 자원을 변경하는 도중에 다른 프로세스나 스레드가 이를 변경하면 예상치 못한 결과가 발생할 수 있습니다.
   - 경쟁 조건은 프로그램의 잘못된 동기화 또는 공유 자원에 대한 부적절한 접근으로 인해 발생할 수 있습니다.

2. 교착 상태 (Deadlock)
   - 교착 상태는 둘 이상의 프로세스나 스레드가 서로의 자원을 기다리면서 무한히 대기하는 상황을 말합니다.
   - 교착 상태는 네 가지 필요 조건인 상호 배제, 점유 대기, 비선점, 순환 대기가 동시에 충족될 때 발생합니다.
   - 각 프로세스나 스레드가 서로의 자원을 점유하고, 서로가 점유한 자원을 기다리면서 무한 대기하는 상황입니다.
   - 교착 상태는 시스템이 더 이상 진행할 수 없게 만들며, 시스템의 성능을 저하시키거나 시스템이 멈추는 원인이 될 수 있습니다.

따라서 경쟁 조건은 동시에 여러 프로세스나 스레드가 공유 자원에 접근할 때 발생하는 예기치 못한 결과를 나타내며, 교착 상태는 둘 이상의 프로세스나 스레드가 서로의 자원을 기다리며 무한히 대기하는 상황을 말합니다.

 

 

교착 상태 발생 조건

1. 상호 배제 (Mutual Exclusion)
   - 하나의 자원이 한 번에 하나의 프로세스나 스레드에 의해만 사용될 수 있어야 합니다.
   - 즉, 자원이 배타적으로 사용될 수 있어야 합니다. 다른 프로세스나 스레드는 해당 자원을 사용할 수 없어야 합니다.

2. 점유 대기 (Hold and Wait)
   - 프로세스나 스레드가 적어도 하나의 자원을 보유한 상태에서 다른 자원을 기다리고 있어야 합니다.
   - 즉, 자원을 보유하고 있는 상태에서 다른 자원을 기다리며, 이러한 상황이 발생하면 교착 상태의 가능성이 있습니다.

3. 비선점 (No Preemption)
   - 자원 할당을 위해 이미 보유한 자원을 강제로 빼앗을 수 없어야 합니다.
   - 즉, 다른 프로세스나 스레드가 이미 점유한 자원을 강제로 빼앗아 사용할 수 없어야 합니다. 자원은 해당 프로세스나 스레드의 명시적인 요청에 의해서만 반환될 수 있어야 합니다.

4. 순환 대기 (Circular Wait)
   - 프로세스나 스레드 간에 순환 형태로 자원을 대기하고 있어야 합니다.
   - 즉, 각 프로세스나 스레드가 서로가 보유한 자원을 기다리며, 이것이 순환적으로 발생하면 교착 상태가 발생할 수 있습니다.

이 네 가지 조건이 동시에 충족될 때 교착 상태가 발생할 가능성이 있습니다. 교착 상태를 방지하기 위해서는 이 네 가지 조건 중 하나 이상을 제거해야 합니다. 일반적으로는 점유 대기와 순환 대기 조건을 제거하는 것이 가장 효과적인 방법입니다.

 

 

방지 방법

1. 상호 배제 (Mutual Exclusion) 방지
   - 상호 배제 조건을 방지하기 위해서는 공유 자원에 대한 접근을 조절하는 메커니즘이 필요합니다.
   - 이를 위해 락(Lock)과 세마포어(Semaphore)와 같은 동기화 기법을 사용합니다.
   - 이러한 동기화 기법을 적절하게 사용하여 한 번에 하나의 프로세스나 스레드만이 자원을 사용할 수 있도록 합니다.

2. 점유 대기 (Hold and Wait) 방지
   - 점유 대기 조건을 방지하기 위해서는 한 번에 모든 필요한 자원을 요청하도록 변경해야 합니다.
   - 이를 위해 프로세스나 스레드는 모든 필요한 자원을 한 번에 요청하고, 요청한 자원이 모두 할당되어야만 실행을 계속할 수 있도록 합니다.
   - 이를 위해 다양한 리소스 할당 그래프 알고리즘을 사용할 수 있습니다. 예를 들어, 자원 요청 그래프(Resource Allocation Graph)를 사용하여 점유 대기 조건을 감지하고, 이를 방지할 수 있습니다.

3. 비선점 (No Preemption) 방지
   - 비선점 조건을 방지하기 위해서는 다른 프로세스나 스레드가 이미 점유한 자원을 강제로 빼앗을 수 있어야 합니다.
   - 이를 위해 자원을 강제로 회수하여 다른 프로세스나 스레드에게 할당할 수 있는 기능이 필요합니다.
   - 일부 운영 체제에서는 우선 순위 기반 스케줄링을 사용하여, 더 높은 우선 순위를 가진 프로세스나 스레드가 다른 프로세스나 스레드의 자원을 강제로 빼앗을 수 있도록 합니다.

4. 순환 대기 (Circular Wait) 방지
   - 순환 대기 조건을 방지하기 위해서는 자원에 번호를 할당하고, 모든 프로세스나 스레드가 자원을 순서대로 요청하도록 변경해야 합니다.
   - 이를 위해 번호가 가장 낮은 자원부터 점유하도록 요청을 변경하거나, 자원에 번호를 할당하여 순환 대기가 발생하지 않도록 합니다.
   - 더 복잡한 방법으로는 은행원 알고리즘(Banker's Algorithm)이 있습니다. 이 알고리즘은 자원 요청 전에 시스템의 상태를 미리 파악하여 교착 상태가 발생하지 않도록 자원을 할당합니다.

이러한 방법들을 적절히 사용하여 교착 상태 조건을 방지할 수 있습니다. 종종 이러한 방법들을 결합하여 보다 효율적인 교착 상태 방지 기법을 구현하기도 합니다.

 

비선점 스케줄링과 선점 스케줄링

1. 선점 스케줄링 (Preemptive Scheduling)
   - 선점 스케줄링은 현재 실행 중인 프로세스가 다른 프로세스에 의해 강제로 중단될 수 있는 스케줄링 방식입니다.
   - 선점 스케줄링은 우선순위 기반(Priority-Based) 스케줄링이나 라운드 로빈(Round Robin) 스케줄링과 같은 방식으로 구현될 수 있습니다.
   - 예를 들어, 우선순위 기반 선점 스케줄링에서는 현재 실행 중인 프로세스보다 더 높은 우선순위를 가진 프로세스가 도착하면 CPU를 강제로 뺏어 해당 프로세스를 실행시킵니다.
   - 또 다른 예로는 라운드 로빈 스케줄링에서는 각 프로세스에 일정한 시간 할당량을 부여하고, 해당 시간이 지나면 다음 프로세스로 CPU가 전환됩니다.

2. 비선점 스케줄링 (Non-preemptive Scheduling)
   - 비선점 스케줄링은 현재 실행 중인 프로세스가 다른 프로세스에 의해 강제로 중단될 수 없는 스케줄링 방식입니다.
   - 대표적인 예로는 FCFS(First-Come, First-Served) 스케줄링이 있습니다. FCFS 스케줄링은 프로세스가 도착한 순서대로 CPU를 할당합니다.
   - 다른 예로는 SJF(Shortest Job First) 스케줄링이 있습니다. 이 스케줄링은 실행 시간이 가장 짧은 프로세스에게 CPU를 먼저 할당합니다.
   - 이러한 스케줄링 방식에서는 현재 실행 중인 프로세스가 종료되거나 입출력을 기다리는 등의 이유로 중단될 때까지 CPU를 계속 보유합니다.

예를 들어, 선점 스케줄링에서는 현재 실행 중인 프로세스가 다른 프로세스에 의해 중단될 수 있습니다. 이는 다양한 우선순위를 가진 프로세스가 도착하여 실행 중인 프로세스보다 높은 우선순위를 가질 때 발생할 수 있습니다. 반면에 비선점 스케줄링에서는 현재 실행 중인 프로세스가 CPU를 릴리스할 때까지 계속 실행됩니다.