ORACLE 데이터베이스 트 랜 잭 션 격 리 단계 소개

두 개의 동시 다발 업무 가 데이터베이스 시트 와 같은 줄 에 동시에 접근 할 때 다음 과 같은 세 가지 문제 가 존재 할 수 있 습 니 다.
1.환상 읽 기:사무 T1 은 where 조건 을 지정 한 문 구 를 읽 고 결과 집합 을 되 돌려 줍 니 다.이때 트 랜 잭 션 T2 는 T1 의 where 조건 을 충족 시 키 기 위해 새 기록 을 삽입 합 니 다.그리고 T1 은 같은 조건 으로 다시 조회 한 결과 T2 가 삽 입 된 기록 을 집중 적 으로 볼 수 있 는데 이 신기록 은 환상 이다.
2.중복 읽 기 불가:사무 T1 은 한 줄 의 기록 을 읽 고 사무 T2 는 T1 이 방금 읽 은 기록 을 수정 한 다음 에 T1 이 다시 조회 한 결과 처음 읽 은 기록 과 다 르 기 때문에 중복 읽 기 불가 라 고 합 니 다.
3.더러 운 읽 기:사무 T1 은 한 줄 의 기록 을 업 데 이 트 했 습 니 다.아직 수정 사항 을 제출 하지 않 았 습 니 다.이 T2 는 업 데 이 트 된 데 이 터 를 읽 은 다음 에 T1 은 스크롤 백 작업 을 수행 하여 방금 수정 한 것 을 취소 합 니 다.그래서 T2 가 읽 은 줄 은 무효 입 니 다.즉,더러 운 데이터 입 니 다.
1.이러한 문 제 를 처리 하기 위해 SQL 표준 은 다음 과 같은 몇 가지 사무 격 리 단 계 를 정의 합 니 다.
READ UNCOMMITTED 환상 읽 기,중복 읽 기,더러 운 읽 기 모두 허용.한 세 션 은 다른 업무 가 제출 하지 않 은 업데이트 결 과 를 읽 을 수 있 습 니 다.이 업무 가 마지막 으로 스크롤 백 으로 끝나 면 읽 기 결과 가 올 바 르 지 않 을 수 있 기 때문에 대부분의 데이터 베 이 스 는 이러한 격 리 단 계 를 사용 하지 않 습 니 다.
READ COMMITTED 는 환상 적 으로 읽 을 수 있 고 중복 읽 을 수 없 으 며 더러 운 읽 을 수 없다.한 세 션 은 다른 트 랜 잭 션 이 제출 한 업데이트 결 과 를 읽 을 수 있 습 니 다.그렇지 않 으 면 기다 림 이 발생 하지만 다른 세 션 은 이 트 랜 잭 션 에서 읽 힌 기록 을 수정 할 수 있 습 니 다.트 랜 잭 션 이 끝 날 때 까지 기다 리 지 않 아 도 됩 니 다.분명 한 것 은 이러한 격 리 단계 에서 한 트 랜 잭 션 의 두 개의 똑 같은 읽 기 동작 은 결과 가 다 를 수 있 습 니 다.
REPEATABLE READ 는 환상 독 서 를 허용 하고 중복 독 서·더러 운 독 서 는 허용 하지 않 는 다.한 업무 에서 두 번 의 같은 조건 의 읽 기 작업 사이 에 기록 을 추가 하 는 작업 이 없 거나 다른 업데이트 작업 이 없 으 면 이 조회 조건 에서 기록 수가 증가 하면 두 번 의 읽 기 결 과 는 같 습 니 다.다시 말 하면 한 사무 에서 처음 읽 은 기록 이 이 사무 기간 에 변경 되 지 않도록 보장 한 다 는 것 이다.SQL Server 는 전체 트 랜 잭 션 기간 동안 읽 은 기록 에 자 물 쇠 를 추가 하여 이러한 격 리 단 계 를 실현 합 니 다.그러면 이 트 랜 잭 션 이 끝 날 때 까지 다른 세 션 은 트 랜 잭 션 에서 읽 은 기록 을 수정 할 수 없고 트 랜 잭 션 이 끝 날 때 까지 만 기다 릴 수 있 습 니 다.그러나 SQL Server 는 다른 세 션 이 표 에 기록 을 추가 하 는 것 을 방해 하지 않 고 다른 세 션 이 다른 기록 을 수정 하 는 것 을 방해 하지 않 습 니 다.
SERIALIZABLE 환상 읽 기,중복 읽 기,더러 운 읽 기 모두 허용 되 지 않 습 니 다.한 업무 에서 읽 기 작업 의 결 과 는 이 업무 가 시작 되 기 전에 다른 업무 가 제출 한 기록 입 니 다.SQL Server 는 전체 업무 기간 에 표 에 자 물 쇠 를 추가 하여 이러한 격 리 단 계 를 실현 합 니 다.이러한 격 리 단계 에서 이 표 의 모든 DML 작업 은 허용 되 지 않 습 니 다.즉,업무 가 끝 날 때 까지 기 다 려 야 합 니 다.그러면 한 업무 에서 두 번 읽 기 작업 의 결 과 는 똑 같 을 것 입 니 다.SQL 표준 이 정의 하 는 기본 트 랜 잭 션 격 리 단 계 는 SERIALIZABLE 입 니 다.
2.Oracle 중의 격 리 등급 과 실현 체제:
Oracle 데이터 베 이 스 는 READ COMMITTED 와 SERIALIZABLE 두 가지 사무 격 리 단계.따라서 Oracle 은 더러 운 읽 기 를 지원 하지 않 습 니 다.즉,Oracle 에 서 는 세 션 이 제출 되 지 않 은 데이터 수정 결 과 를 읽 는 것 을 허용 하지 않 아 트 랜 잭 션 스크롤 로 인해 읽 기 가 올 바 르 지 않 습 니 다.
Oracle 스크롤 백 은 데이터 기록 을 수정 할 때 이 기록 들 이 수정 되 기 전의 결 과 를 스크롤 백 이나 취소 세그먼트 에 저장 합 니 다.Oracle 읽 기 작업 은 업데이트 작업 을 방해 하지 않 고 업데이트 작업 도 읽 기 작업 을 방해 하지 않 습 니 다.그러면 Oracle 의 각종 격 리 단계 에서 읽 기 작업 은 업데이트 업무 가 끝 날 때 까지 기다 리 지 않 습 니 다.업데이트 작업 도 다른 업무 에서 읽 기 작업 으로 인해 기다 리 지 않 습 니 다.이것 도 Oracle 사무 처리 의 장점 입 니 다.
Oracle 이 부족 한 설정 은 Read Committed 격 리 단계(구문 등급 의 격 리 라 고도 함)입 니 다.이러한 격 리 단계 에서 한 업무 가 특정한 표 에 DML 작업 을 수행 하고 있 을 때 다른 세 션 이 이 표 의 기록 에 대해 읽 기 작업 을 수행 하면 Oracle 은 스크롤 백 이나 취소 단계 에 저 장 된 업데이트 전의 기록 을 읽 습 니 다.SQL Server 처럼 업데이트 가 끝 날 때 까지 기다 리 지 않 습 니 다.
Oracle 의 Serializable 격 리 단계(사무 단계 의 격 리 라 고도 함)는 사무 에서 읽 기 동작 은 이 사무 가 시작 되 기 전에 제출 한 데이터 결과 만 읽 을 수 있 습 니 다.읽 을 때 다른 사무 가 기록 을 수정 하고 있 으 면 Oracle 은 스크롤 백 이나 취소 세그먼트 에서 수정 되 지 않 은 기록 을 찾 습 니 다.(또한 작업 이 시작 되 기 전에 스크롤 백 이나 취소 세그먼트 에 저 장 된 기록 을 읽 습 니 다)이 때 읽 기 작업 도 해당 기록 이 업데이트 되 어 기다 리 지 않 습 니 다.
격 리 단 계 를 설정 하려 면 SET TRANSACTION ISOLATION LEVEL[READ UNCOMMITTED|READ COMMITTED|REPEATABLE READ|SERIALIZABLE]을 사용 하 십시오.
다음은 Oacle 설정 SERIALIZABLE 격 리 단계 의 예제 입 니 다.

왼쪽 은 사무 T1,오른쪽 은 사무 T2,T2 레벨 은 SERIALIZABLE 이기 때문에 사무 T1 이 데 이 터 를 제출 한 후에 도 사무 T2 는 T1 이 제출 한 데 이 터 를 볼 수 없고 환상 적 인 읽 기와 중복 읽 기 가 허용 되 지 않 습 니 다.
그러면 어떻게 T1 이 새로 추 가 된 기록 을 볼 수 있 습 니까?위의 T1 과 T2 는 동시에 실 행 됩 니 다.T1 이 insert 를 실 행 했 을 때 T2 는 이미 시작 되 었 습 니 다.T2 등급 은 SERIALIZABLE 이기 때문에 T2 가 조회 한 데이터 세트 는 T2 사무 시작 전 데이터 베이스 입 니 다.즉,사무 T1 은 사무 T2 가 시 작 된 후의 insert 와 update 작업 의 영향 이 사무 T2 에 영향 을 주지 않 습 니 다.이제 하나의 트 랜 잭 션 T3 를 다시 시작 하면 T1 에 추 가 된 기록 을 볼 수 있 습 니 다.
다음 이벤트 가 발생 하면 트 랜 잭 션 이 시 작 됩 니 다.1.데이터 베 이 스 를 연결 하고 첫 번 째 DML 문 구 를 실행 합 니 다.2.이전 트 랜 잭 션 이 끝 난 후에 다른 DML 문 구 를 입력 합 니 다.