오라클 성능 고도화 원리와 해법 1 - 트랜잭션과 Lock_Day6

About this offer

4. 동시성 구현 사례 일련번호 채번 시 MAX(번호) + 1 방식을 사용할 경우, 두 트랜잭션이 동시에 동일한 MAX 값을 조회했을 때 발생할 수 있는 문제를 설명하시오. 두 트랜잭션이 동시에 동일한 MAX 값을 조회하면, 둘 다 같은 다음 번호를 생성할 수 있다. 이후 동일한 키 값으로 INSERT를 시도하면 PK 제약조건 위반 오류가 발생한다. 채번 테이블을 사용할 때, 현재 채번 값을 조회하기 전에 해당 행의 값을 먼저 UPDATE하는 이유를 설명하시오. 채번 값을 먼저 UPDATE하는 이유는 해당 채번 행에 Lock을 설정하여 동일한 구분값에 대한 채번 작업을 직렬화하기 위해서다. 다른 트랜잭션이 같은 행의 번호를 채번하려 하면 앞선 트랜잭션이 Lock을 해제할 때까지 대기하게 되므로 동일 번호가 동시에 발급되는 것을 방지할 수 있다. 채번 함수 내부에서 COMMIT을 수행하되 Autonomous Transaction을 사용하지 않은 경우, 메인 트랜잭션에 발생할 수 있는 문제를 설명하시오. Autonomous Transaction을 사용하지 않은 상태에서 채번 함수 내부에서 COMMIT하면, 채번 함수 호출 이전에 메인 트랜잭션에서 수행한 작업까지 함께 커밋된다. 이후 메인 로직에서 오류가 발생해 ROLLBACK하더라도 이미 커밋된 이전 작업은 되돌릴 수 없으므로 트랜잭션의 원자성이 깨지고 데이터 일관성 문제가 발생할 수 있다. Autonomous Transaction을 채번 함수에 적용했을 때, 일반 트랜잭션과 비교하여 얻을 수 있는 효과를 설명하시오. Autonomous Transaction을 사용하면 채번 함수 내부의 작업이 메인 트랜잭션과 독립된 별도 트랜잭션으로 수행되므로, 채번 함수 내부의 COMMIT 또는 ROLLBACK이 메인 트랜잭션의 작업에 영향을 주지 않는다. 또한 채번용 행의 Lock을 서브 트랜잭션에서 빠르게 해제할 수 있어 채번 동시성도 높일 수 있다. 채번 함수에서 Autonomous Transaction을 사용하지 않고 COMMIT도 제거한 경우, 동시성 측면에서 발생할 수 있는 문제를 설명하시오. 채번 함수 내부에서 COMMIT을 제거하면 채번 행에 설정된 Lock이 함수 종료 시점에 해제되는 것이 아니라 메인 트랜잭션이 종료될 때까지 유지된다. 따라서 채번 이후의 메인 로직 수행 시간이 길어질수록 같은 채번 행을 사용하려는 다른 트랜잭션의 대기 시간도 길어져 동시성이 저하될 수 있다. 선분이력 관리 시 현재 이력 행에 SELECT ... FOR UPDATE를 수행하여 동시성을 제어하려 할 때, 해당 고객의 기존 이력이 전혀 없는 경우 발생할 수 있는 문제를 설명하시오. 기존 이력 행이 없으면 SELECT ... FOR UPDATE가 잠글 대상 자체가 없으므로 Lock이 설정되지 않는다. 그 결과 동일 고객에 대한 여러 트랜잭션이 동시에 INSERT까지 진입할 수 있고, 시작일시는 서로 다르지만 종료일시가 모두 9999-12-31인 현재 이력 행이 여러 건 생성되어 선분이력의 정합성이 깨질 수 있다. 기존 이력이 없는 경우에도 선분이력의 동시성을 제어하기 위해, 어떤 행을 SELECT ... FOR UPDATE 대상으로 사용해야 하는지 설명하시오. 기존 이력이 존재하지 않아 이력 테이블에서 잠글 행이 없는 경우에는, 항상 존재하는 상위 테이블의 해당 고객 행을 SELECT ... FOR UPDATE로 잠가 동시성을 제어하면 된다. 교재 예시에서도 특정 고객의 상위 행을 잠금 대상으로 사용하여 동일 고객에 대한 동시 작업을 직렬화한다. 선분이력의 동시성 제어를 위해 상위 고객 테이블의 특정 고객 행을 잠그는 방식이 전체 시스템의 동시성에 미치는 영향을 설명하시오. 상위 고객 테이블 전체를 잠그는 것이 아니라 해당 고객의 특정 행만 SELECT ... FOR UPDATE로 잠그기 때문에, 동일 고객에 대한 작업만 직렬화되고 다른 고객에 대한 작업은 동시에 진행할 수 있다. 따라서 교재에서도 전체 동시성에 미치는 영향은 거의 0에 가깝다고 설명한다. 5. 오라클 Lock (1~2) Enqueue Lock의 특징을 소유자(Owner), 대기자(Waiter), Queue의 관점에서 설명하시오. Enqueue Lock 은 공유 리소스 에 대해 Lock을 요청하는 세션을 소유자(Owner)와 대기자(Waiter)로 구분하고, 대기자를 Queue 형태로 관리한다. TX Lock이 획득되는 시점과 해제되는 시점을 각각 설명하시오. TX Lock은 트랜잭션이 첫 번째 변경 작업을 시작할 때 획득하고, COMMIT 또는 ROLLBACK 시 해제된다. 한 트랜잭션이 특정 행을 수정 중일 때, 다른 트랜잭션이 해당 행에 대해 일반 SELECT를 수행하는 경우와 UPDATE를 수행하는 경우의 동작 차이를 설명하시오. 일반 SELECT는 선행 트랜잭션의 행 Lock을 기다리지 않고, 필요하면 Undo 정보를 이용해 CR Block을 생성하여 일관성 읽기를 수행한다. 같은 행에 대한 UPDATE는 변경 작업을 직렬화해야 하므로, 선행 트랜잭션이 보유한 TX Lock이 해제될 때까지 대기한다. 하나의 트랜잭션이 여러 개의 행을 수정하는 경우, TX Lock과 각 행의 Lock Byte가 어떤 단위로 관리되는지 설명하시오. TX Lock : 트랜잭션 단위로 관리 Lock Byte* : 각 행 단위로 존재 행의 Lock Byte를 통해 현재 해당 행을 수정 중인 트랜잭션을 확인하는 과정을 ITL과 Transaction ID의 관점에서 설명하시오. Lock Byte → 해당 ITL 슬롯 → ITL의 Transaction ID → 해당 트랜잭션의 Active 여부 확인 대상 행의 Lock Byte가 가리키는 ITL을 통해 해당 행을 변경한 트랜잭션을 식별하고, 그 트랜잭션이 아직 Active 상태이면 후행 트랜잭션은 대기하게 된다. enq: TX - row lock contention 대기 이벤트가 발생하는 대표적인 상황을 설명하시오. enq: TX - row lock contention은 대표적으로 후행 트랜잭션이 선행 트랜잭션이 이미 변경 중인 동일한 행을 변경하려고 할 때, 선행 트랜잭션의 TX Lock 해제를 기다리는 상태를 의미한다.