안녕하세요, BTC 24/365팀입니다.
이번 포스팅에서는 Oracle DB의 물리적 구조에 대해 알아보도록 하겠습니다.
![](https://t1.daumcdn.net/keditor/emoticon/niniz/large/047.gif)
목차
1. Isolation Level
2. Lock 종류
3. Lock 설정 레벨
4. Row Lock 예시
5. Dead Lock 예시
1. 트랜잭션 격리수준(Isolation Level)
- 동시에 여러 트랜잭션이 처리될 때, 트랜잭션끼리 얼마나 서로 고립되어 있는지를 나타내는 것
- 특정 트랜잭션이 다른 트랜잭션이 변경한 데이터를 볼 수 있도록 허용할지 말지를 결정하는 것
2. Lock 종류 (아래 Lock 이외에도 다양한 Lock이 존재함)
■ 공유 락 (Shared Lock)
- 여러 유저가 동시에 데이터 읽더라도 데이터 일관성에 아무런 영향을 주지 않기 때문에, Shared Lock 끼리는
데이터에 동시접근이 가능함
- 자원에 대해 수행되는 명령의 유형에 따라 lock된 자원의 공유가 허용됨
- Shared Lock은 Read Lock이라고도 불리며 데이터를 변경하지 않는 읽기 명령에 대한 Lock으로 shared의
앞 글자를 따서 주로 s로 표기함
■ 베타 락 (Exclusive Lock)
- Exclusive Lock은 데이터를 변경하고자 할 때 사용되며. 트랜잭션이 완료될 때까지 유지되며 Lock이 해제될 때까지
다른트랜잭션은 해당 리소스에 접근이 불가능함
- Lock이 걸린 자원의 공유를 허용하지 않음
- Exclusive Lock의 경우 데이터 변경이 되는 명령들에게 해당하는 Lock으로 Write Lock으로 불리며, x로 표기함
3. Lock 설정 레벨
■ 데이터 베이스
- 전체 DB를 기준으로 Lock 발생
- 1개의 세션이 하나의 DB의 데이터에 접근 할 수 있음
- DB 업데이트와 같은 작업에 발생
■ 파일
- DB 파일을 기준으로 Lock이 걸림
- 파일 전체를 백업할 때 Lock이 생성됨
■ 테이블
- 테이블 기준으로 Lock이 발생
- 전체 테이블에 대한 데이터 변경이 일어날 때 Lock 발생
- DDL 구문을 사용할 때 발생되어 DDL Lock이라고도 불림
■ 페이지와 블럭
파일을 구성하는 페이지와 블록을 기준으로 Lock 발생
■ 컬럼 (Column)
- 컬럼 기준으로 Lock 발생
- Lock 설정 및 해제 시 리소스가 많이 발생하여 잘 사용하지 않음
■ 행(Row)
- 행 수준의 Lock 발생
- 가장 많이 발생하는 Lock
4. Row Lock 예시
- 트랜잭션 1번이 EMPLOYEE_ID = 201에 대해 UPDATE
- 트랜잭션 2번이 EMPLOYEE_ID = 201에 대해 UPDATE를 QUERY를 실행하지만 1번 트랜잭션이 COMMIT을
찍지 않아서 트랜잭션 2번에 대한 UPDATE는 진행되지 않음
- 트랜잭션 1번이 COMMIT을 치면 이후에 밀려있던 트랜잭션 2번의 UPDATE SQL이 실행됨
5. Dead Lock 예시
- 프로세스가 자원을 얻지 못해 다음 처리를 하지 못하는 상태로 '교착상태'라고도 하며 시스템적으로
한정된 자원을 여러 곳에서 사용하려 할 때 발생
- 트랜잭션 1번이 EMPLOYEE_ID = 202번에 대해 UPDATE를 진행
- 트랜잭션 2번이 EMPLOYEE_ID = 201번에 대해 UPDATE를 진행
- 트랜잭션 1번이 EMPLOYEE_ID = 201번에 대해 UPDATE를 진행
- 트랜잭션 2번이 EMPLOYEE_ID = 202번에 대해 UPDATE를 진행
- 서로가 원하는 리소스가 상대방에게 할당되어 있기 때문에 두 프로세스는 무한정 기다리게 됨
- 하나의 프로세스를 KILL해서 해결
'Database' 카테고리의 다른 글
[24/365] Data Dictionary (0) | 2022.07.20 |
---|---|
[24/365] RAC와 HA의 정의와 차이점 (0) | 2022.07.01 |
NoSQL에 등장 배경과 특징 (0) | 2022.06.17 |
[24/365]AWS DMS 소개 (0) | 2022.06.14 |
반 정규화(De-normalization) (0) | 2022.06.10 |
댓글