[Oracle] Oracle Archtecture(7) [Lock]

락(Lock)

"데이터를 보호하는 장치"

• 오라클에서 락은 단순한 '잠금'이 아니라, 데이터의 일관성(Consistency)과 무결성(Integrity)을 유지하기 위한 핵심 장치입니다. 여러 사용자가 동시에 같은 데이터를 수정할 때 발생할 수 있는 '데이터 꼬임'을 방지하죠.

 

• 데이터 보호: 한 세션이 특정 데이터를 수정하고 있다면, 그 작업이 끝날 때까지(Commit/Rollback) 다른 세션은 해당 데이터를 변경할 수 없도록 잠급니다.
• 동시성 제어: "누가 먼저 왔는가?"를 명확히 하여 데이터가 이중으로 수정되는 대참사를 막습니다.

---

락의 종류

Oracle Lock 종류

 

 

1. DML Lock (Data Manipulation Language Lock)

• 데이터를 수정, 삽입, 삭제할 때 발생하는 락입니다. 가장 빈번하게 마주치며 실무 장애의 90%를 차지합니다.
• DML락은  여러 사용자가 동시에 액세스하는 데이터의 무결성을 보장합니다. ex) 두 고객이 온라인 서점에서 구할 수 있는 마지막 책을 동시 구매하는 것을 방지
• DML Lock 종류
  1. TX (Transaction Lock) - "행(Row) 단위 락"
     •  상황: 특정 Row를 수정할 때 발생합니다. 
     •  역할: 특정 데이터 '줄(Row)'을 보호합니다.
     •  특징: 수정 중인 행에만 TX 락을 겁니다. 덕분에 해당 행은 다른 트랜잭션이 행을 수정할 수 없습니다. 커밋(Commit)/롤백(Rollbcak) 전까지는 절대 풀리지 않습니다.
  2. TM (Table Metadata Lock) - "테이블(Table) 단위 락"[TM 락의 5가지 모드 상세]
     • RS (Row Share): 특정 행을 수정할 '예정'임을 나타내는 가장 가벼운 락입니다. (SELECT ... FOR UPDATE 시 발생)
       •  모든 작업(조회, 다른 행 수정, 같은 행 수정 시도)이 가능하지만, 테이블을 통째로 지우거나 수정하는 것(X 락)만 막습니다.
     • RX (Row Exclusive): 테이블 내의 특정 행(Row)을 수정 중임을 나타내는 락입니다. 단순조회(SELECT), 다른 Row 수정은 가능합니다.(일반적인 INSERT, UPDATE, DELETE 시 발생)
       •  단순 조회(SELECT)와 다른 행 수정은 가능하지만, 테이블 전체에 영향을 주는 작업(DDL)은 차단합니다.
     • S (Share): 테이블 '전체를 읽고 분석 중'임을 나타내는 락입니다(인덱스 생성 시 주로 발생)
       •  테이블 전체에 대한 '읽기 전용' 권한을 선언하는 것으로, 다수의 사용자가 동시에 조회하는 것은 허용하지만 트랜잭션의 정합성을 위해 모든 데이터 변경 작업(DML)을 완벽히 차단합니다.
     • SRX (Share Row Exclusive): 테이블 전체를 읽으면서 '나만 수정하겠다'는 강력한 독점 락입니다. (주로 FK 관계 작업 시 발생)
       •  오직 단순 조회(SELECT)만 가능하며, 나를 제외한 그 누구의 데이터 수정이나 공유 락 획득을 차단합니다.
     • X (Exclusive): 테이블 '구조 자체를 변경 중'임을 나타내는 최고 등급의 락입니다.
       •  단순 조회(SELECT) 외의 모든 접근을 차단합니다. (사실상 모든 트랜잭션이 멈춥니다.)

 

2. DDL Lock (Data Definition Language Lock)

테이블이나 뷰 같은 객체의 구조(Schema)를 보호하는 락입니다. ALTER, DROP 등을 할 때 오라클이 내부적으로 자동으로 관리합니다.

 

1. Exclusive DDL Lock - "독점 구조 변경"

• 상황: DROP TABLE이나 ALTER TABLE을 할 때 발생합니다.
• 역할: 내가 구조를 바꾸는 동안 다른 사람이 그 테이블을 읽거나 수정하는 것을 완전히 차단합니다.

2. Share DDL Lock - "공유 구조 보호" 

• 상황: 패키지나 프로시저를 컴파일할 때 발생합니다.
• 역할: 내가 이 테이블을 참조하는 프로그램을 만드는 동안, 다른 사람이 테이블 구조를 바꾸지 못하게 막습니다. (하지만 여러 명이 동시에 '읽기'용도로 Share 락을 잡는 건 가능합니다.)

3. Breakable Parse Lock - "파싱 정보 보호"

• 역할: SQL 실행 계획(Library Cache)이 유효한지 체크합니다.
• 특징: 이름 그대로 '깨지기 쉬운' 락입니다. 만약 해당 SQL이 참조하는 테이블의 구조가 바뀌면, 이 락은 즉시 깨지고 실행 계획을 새로 만듭니다(Hard Parse).

---

💡시나리오로 감 잡기

1. "데이터 한 줄 수정 중인데, 왜 테이블 삭제(DROP)가 안 될까?"

• 상황: 서비스 점검을 위해 안 쓰는 테이블을 삭제하려고 DROP TABLE을 실행했습니다. 그런데 명령어가 끝나지 않고 무한 대기 중입니다.

👇원인과 해결

• 원인: 데이터 수정 시 TX 락이 걸리면서 동시에 테이블 전체에 TM RX(Row Exclusive) 락이 걸리기 때문입니다. DROP 명령은 TM X(Exclusive) 락을 필요로 하는데, RX와 X는 서로 양립할 수 없습니다. 
• 해결: 데이터를 수정 중인 세션(TX 락 보유자)이 커밋이나 롤백을 할 때까지 기다리거나, 해당 세션을 찾아 종료해야 합니다.

 

2.  "테이블 컬럼 하나 추가했을 뿐인데, 왜 운영 서버 CPU가 폭주할까?"

• 상황: 아주 한가한 시간에 테이블에 컬럼을 하나 추가했습니다. 그런데 그 직후부터 평소 잘 돌아가던 SQL들의 성능이 급격히 떨어지며 서버 부하가 치솟습니다.

👇원인과 해결

• 원인: 이미지 하단의 Breakable Parse Lock 때문입니다. 기존 SQL들은 실행 계획을 메모리에 저장하며 이 락을 걸어둡니다. 테이블 구조가 바뀌는 순간 이 락들이 일제히 'Break(파괴)' 되고, 수만 개의 세션이 동시에 실행 계획을 새로 만드느라(Hard Parse) CPU를 과점하게 된 것입니다.
• 해결: 운영 중 DDL 작업은 아주 신중해야 합니다. 대규모 서비스라면 영향도를 파악한 뒤 트래픽이 가장 적은 시간에 수행하는 것이 정석입니다.

 

3. "인덱스 생성(CREATE INDEX) 중에 왜 데이터 입력이 안 될까?"

• 상황: 서비스 속도를 높이려고 운영 중에 인덱스를 만들고 있습니다. 그런데 갑자기 결제 시스템에서 에러가 터지기 시작합니다.

👇원인과 해결

• 원인: 일반적인 인덱스 생성 시 테이블에는 TM S(Share) 락이 걸립니다. "나 지금 테이블 전체를 훑어서 인덱스 만드는 중이니, 데이터 수정은 잠시 멈춰!"라는 뜻입니다. 이때 사용자의 INSERT는 TM RX 락을 요청하지만, S와 RX는 공존할 수 없습니다.
• 해결: 운영 중에 인덱스를 만들 때는 ONLINE 옵션(CREATE INDEX ... ONLINE)을 사용해야 합니다. 그러면 오라클이 내부적으로 락의 강도를 낮춰 서비스 중단 없이 인덱스를 생성합니다.

 

4. "다른 유저들이 같은 데이터를 수정하려 할 때 왜 화면이 멈춘 채 응답이 없을까?"

• 상황: 한 직원이 고객 정보를 수정(UPDATE)하다가 전화를 받으러 자리를 비웠습니다. 그런데 커밋(Commit)을 안 눌렀네요.

👇원인과 해결

• 원인: 이미지의 TX Lock 때문입니다. 먼저 수정한 세션이 확정을 지을 때까지 뒤에 온 세션들은 **Enqueue(대기열)**에 쌓여 무한 대기합니다.
• 해결: v$session에서 blocking_session을 찾아 범인 SID를 확인하고, ALTER SYSTEM KILL SESSION으로 강제 종료시켜 락을 회수합니다.