Oacle 의 잠 금 에 대한 깊 은 이해

ORACLE 에는 다음 과 같은 몇 가지 모드 가 있 습 니 다.0:none 1:null 빈 2:Row-S 줄 공유(RS):공유 표 잠 금 3:Row-X 줄 전용(RX):줄 수정 에 사용 되 는 4:Share 공유 잠 금(S):다른 DML 작업 을 막 기 5:S/Row-X 공유 줄 전용(SRX):다른 작업 을 막 기 6:exclusive 전용(X):독립 적 인 접근 사용
숫자 가 클 수록 잠 금 단계 가 높 아 지고 영향 을 주 는 조작 이 많 습 니 다.1 레벨 잠 금:Select,가끔 v$lockedobject 가 나타나다.
2 단계 잠 금:Select for update,Lock For Update,Lock Row Share select for update 대화 에서 for update 하위 문자열 로 커서 를 열 때 집 중 된 모든 데이터 줄 은 줄 급(Row-X)독점 잠 금 상태 이 며,다른 대상 은 이 데이터 줄 만 조회 할 수 있 으 며,update,delete 또는 select for update 작업 을 할 수 없습니다.
3 레벨 잠 금:Insert,Update,Delete,Lock Row Exclusive 는 commt 가 없 기 전에 같은 기록 을 삽입 하면 반응 이 없습니다.다음 3 의 자 물 쇠 는 이전 3 의 자 물 쇠 를 계속 기다 리 기 때문에 우 리 는 하 나 를 풀 어야 계속 일 할 수 있 습 니 다.
4 레벨 잠 금:Create Index,Lock Share lockedmode 는 2,3,4 로 DML(insert,delete,update,select)작업 에 영향 을 주지 않 지만 DDL(alter,drop 등)작업 은 ora-00054 오 류 를 알려 줍 니 다.
ORA-00054:resource busy and acquire with NOWAIT specified(ORA-00054:자원 이 바 쁘 지만 NOWAIT 방식 으로 자원 을 가 져 오도 록 지정)
5 레벨 잠 금:Lock Share Row Exclusive 구체 적 으로 주 외 키 제약 이 있 을 때 update/delete...;4,5 의 자물쇠 가 생 길 수 있 습 니 다.
부모 표를 수정 할 때 하위 표 에 대응 하 는 기록 이 존재 하면 ORA-02292 이상 이 발생 합 니 다.그렇지 않 으 면 부모 시계 에 TX 자물쇠 와 RX 자물쇠 만 추가 합 니 다.
서브 시트 를 수정 할 때 서브 시트 에 TX 자물쇠 와 RX 자 물 쇠 를 추가 하 는 것 을 제외 합 니 다.아버지 표 에 도 SS 자 물 쇠 를 넣 었 습 니 다.이것 은 논리 에 부합 합 니 다.아버지 표 는 이때 참고 완전 성 을 만족 시 켜 야 하기 때 문 입 니 다.즉,부모 표 에 SS 자 물 쇠 를 추가 하여 이때 부모 표 에 대해 수정 작업 을 하지 않도록 하 는 것 이다.
위의 자물쇠 가 말 한 수정 은 모두 하위 부모 표 에 완전한 필드 작업 을 참고 하 는 것 입 니 다.
6 레벨 잠 금:Alter table,Drop table,Drop Index,Truncate table,Lock Exclusive 는 DBA 역할 로:

col owner for a12
col object_name for a30
col machine for a32
    col USERNAME for a16
    col OSUSER for a16

    현재 세 션 사 이 드 보기:    select sid from v$mystat where rownum<=1 ;    현재 세 션 상황 보기:    select machine,username,sid,serial#,type,osuser,status from v$session;    현재 데이터베이스 에 잠 겨 있 는 상황 을 보면 다음 과 같은 SQL 문 구 를 사용 할 수 있 습 니 다

select s.username,o.object_name,s.machine,s.sid,s.serial#,k.type
from v$locked_object l,dba_objects o ,v$session s,v$lock k
where l.object_id  =  o.object_id and l.session_id=s.sid and k.sid=s.sid

장기 적 으로 나타 나 는 열 이 있 으 면 풀 리 지 않 은 자물쇠 일 수 있 습 니 다.우 리 는 다음 SQL 문 구 를 사용 하여 장기 적 으로 비정상적인 자 물 쇠 를 풀 지 않 은 것 을 죽 일 수 있 습 니 다.alter system kill session'sid,serial\#';자물쇠 에 문제 가 생기 면 어떤 DML 조작 이 오랫동안 기 다 려 반응 이 없 을 수도 있다.
위의 명령 을 이용 하여 프로 세 스 를 죽 인 후 프로 세 스 상 태 는"killed"로 설정 되 었 으 나 잠 긴 자원 이 오랫동안 방출 되 지 않 았 다 면 os 1 급 에서 해당 프로 세 스(스 레 드)를 죽 일 수 있 습 니 다.먼저 아래 문 구 를 실행 하여 프로 세 스(스 레 드)번 호 를 얻 을 수 있 습 니 다

select spid, osuser, s.program
from v$session s,v$process p
where s.paddr=p.addr and s.sid=#sid （#sid      sid）

4.OS 에서 이 프로 세 스(스 레 드)를 죽 일 수 있 습 니 다.1)유 닉 스에 서.루트 로 명령 을 수행 합 니 다:\#kill-9\#spid(즉,위 에서 찾 은 spid)2)는 windows 에서 Oacle 로 스 레 드 를 죽 입 니 다.Oacle 은 Oacle 이 제공 하 는 실행 가능 한 명령 입 니 다.문법 은 Oacle sid thread 입 니 다.sid:죽 일 프로 세 스 가 속 하 는 인 스 턴 스 이름 thread:죽 일 스 레 드 번호,즉 위 에서 찾 은 spid 입 니 다.예:c:>orakill orcl\#spid 는 데이터 베 이 스 를 직접 연결 하 는 방식 을 사용 하고 OS 시스템 명령 으로$kill process 를 사용 하지 마 십시오.num 혹은$kill-9 processnum 은 사용자 연결 을 중지 합 니 다.한 사용자 프로 세 스 가 하나 이상 의 자 물 쇠 를 만 들 수 있 기 때문에 OS 프로 세 스 를 죽 이 는 문제 가 발생 할 수 있 습 니 다.rs 와 rx 의 차 이 는 어디 에 있 습 니까?Row Exclusive(RX):INSERT,UPDATE,DELETERow Share(RS):SELECT...FOR UPDATE 둘 다 TM table lock modes held by DML transactions.아니면 약간의 차이 가 있 습 니까?하 나 는 생 긴 것 이 다 릅 니 다.둘째,rx 잠 금 후 다른 transactions 는 변 경 된 결 과 를 읽 지 못 합 니 다.rs 는 다른 transactions 에 있어 서 읽 는 것 은 문제 가 없 기 때문에 rs 라 고 부른다.표 차원 에서 Prevents other transactions from manually locking the table 을 말 하지만 하 나 는 for exclusive reading or writing 이 고 다른 하 나 는 for exclusive write access 입 니 다.이것 이 바로 rs 의 s(share)가 표현 하 는 곳 입 니 다.