230208 수요일
Data 충돌 = Session 충돌 = Lock 충돌
📚 1. Lock
- 변경 작업 발생시 DBMS는 관련 행 단위로 Lock을 구현하고 작업을 진행한다.
- Lock 트랜잭션 진행 중에는 유지되고, 트랜잭션 종료 시 해제된다.
- Lock이 구현된 곳에서 작업이 요청되는 경우 큐라고 하는 대기공간에서 기다린다.
📚 2. Lock 충돌
- Waiting이 길어지는 경우 Lock 충돌로 감지하고 해결해야함.
📚 3. Lock 충돌의 원인
- 트랜잭션을 길게 진행하는 경우
- 커밋되지 않은 작업이 남아있는 경우
📚 4. Lock 충돌 해결 방법(모니터링 방법)
- v$session : DB에 접속된 세션 정보와 Lock 충돌 정보를 모니터링 할 수있는 DB 사전
👉 블로킹의 원인인 세션을 알아낼수있다.
📚 5. Session Kill 시키기
- DBA 권한 필요하다! (sys사용자)
SQL> alter system kill session 'SID, Serial#' immediate;
🚨 waiting이 걸림
👉 sys 사용자에서 블로킹의 원인이 된 세션 kill
🙆♀️ waiting이 끝나고 작업 성공함
🙆♀️ 세션을 kill했으니 hr 접속이 끊김!
📚 6. Lock 충돌의 특이케이스 : Deadlock(교착상태)
- 두 세션이 각자의 자원을 선점한 상태에서 상대방의 자원을 서로 요청하는 경우
- Deadlock을 특수한 경우이므로 DBMS에 의해서 자동 감지되고 해결된다.
- 한쪽 세션으로 Deadlock 오류 메세지가 자동으로 발생되면서 해결된다.
Deadlock 오류메세지 뜬 세션이 양보해야한다.
데드락이 원인이 된 곳 전까지 commit/rollback 가능하다.
🚨 C1과 C2가 Deadlock이 걸린 상태
👉 C1에 오류 메세지가 발생
👉 C2에는 waiting
❗ C1에 rollback 하자마자
🙆♀️ C2에 작업 성공!
