1장 7절: Consistent vs. Current 모드 읽기

2015. 9. 15. 23:01

*참고 1: 언두 세그먼트 확인 쿼리

select s.sid, s.serial#, t.xidusn, t.used_ublk, t.used_urec

from v$session s, v$transaction t

where t.addr = s.taddr

--and s.sid = 144;


*참고 2: SCN 확인 쿼리

select current_scn, scn_to_timestamp(current_scn)

from v$database;


----------------------------------

61~ 70 p 읽기 일관성 실습내용

*기본 제공 HR스키마에서 연습


- 확인 쿼리

select employee_id, salary

from employees

where employee_id = 100;


- 복원 쿼리

update employees set salary = 1000

where employee_id = 100;

commit;


(상황1)


<TX1>

update employees set salary = salary + 100

where employee_id = 100;


commit; --> 1 rows updated


<TX2>

update employees set salary = salary + 200

where employee_id = 100;


commit; --> 1 rows updated


예측 : salary = 1300

확인 : salary = 1300 --> 검증 성공


(상황2)


<TX1>

update employees set salary = 2000

where employee_id = 100

and salary = 1000;


commit; --> 1 rows updated


<TX2>

update employees set salary = 3000

where employee_id = 100

and salary = 2000;


commit; --> 0 rows updated


예측 : salary = 2000

확인 : salary = 2000 --> 검증 성공



(상황3)

--> 일단 사고 실험

예측 : 50,000건 갱신

이유 : Consistent 모드로 갱신대상을 식별하는데, update 문 실행 시점(t1)이 insert 문 실행 시점(t2)보다 앞서므로 t3시점에서 TX2가 commit 되더라도 식별 대상 자체에서 제외되므로 아예k가 업데이트 되지 않는다..


--> 숫자를 10000 --> 10으로 줄여 실험해보자.


- 확인 쿼리

select * from t1;


conn user01/oracle

create table t1 (a varchar(2), no number);

insert into t1 (a,no) values ('a',1);

insert into t1 (a,no) values ('b',2);

insert into t1 (a,no) values ('c',3);

insert into t1 (a,no) values ('d',4);

insert into t1 (a,no) values ('e',5);

insert into t1 (a,no) values ('f',6);

insert into t1 (a,no) values ('g',7);

insert into t1 (a,no) values ('h',8);

insert into t1 (a,no) values ('i',9);

insert into t1 (a,no) values ('j',10);

commit;


<TX1>

update t1 set no = no +1

where no > 5;


commit; --> 5 rows updated


<TX2>

insert into t1 (a,no) values ('k',11);

commit; --> 1 rows created


예측 결과 집합

(a,1) (b,2) (c,3) (d,4) (e,5) (f,7)

(g,8) (h,9) (i,10) (j,11) (k,11) --> 검증 성공!



(상황4)


<TX1>

update employees set salary = salary + 100

where employee_id = 100

and salary = 1000;


commit; --> 1 rows updated


<TX2>

update employees set salary = salary + 200

where employee_id = 100

and salary = 1000;


commit; --> 0 rows updated


예측 : salary = 1100

확인 : salary = 1100 --> 검증 성공


--> 설명

상황 1, 2, 4

오라클에서는 update(및 delete, merge)를 수행할 때,

단계(1) Consistent Mode로 Update 대상을 식별한 후

단계(2) Current Mode로 실제 Update를 수행하나, 그냥 수행하는게 아니라

Current Mode로 다시 한번 where 조건을 체크한 후 부합하는 레코드만 Update를 수행한다.


상황1: 두 번 체크할 때 모두 부합하므로 TX2가 성공하였다.

상황2: 애초에 1단계에서 Consistent Mode로 체크할 때 where절 조건이 일치하지 않으므로 실패한다.

상황4: 1단계는 성공하였으나, 2단계에서 Current Mode로 체크할 때 where절 조건이 일치하지 않으므로 실패한다.


★ 상황 2와 상황 4의 중요한 차이점은, 상황 2에서는 1단계에서 바로 실패하므로 TX1의 Exclusive Lock이 해제 될 때까지 대기할 필요 없이 바로 실패 메시지(0 rows updated)를 띄우지만, 상황4에서는 2단계(t3시점의 TX1 commit시점)에서 Current Mode로 재검증 시 실패할 때야 비로소 실패 메시지를 띄운다는 것이다. 실험을 통해서 직접 확인 할 수 있다.


검증해보자!

곰돌곰둘 Oracle_DB_Unix admin/(2)오라클 성능 고도화 1권

LGWR의 활동주기

2015. 8. 16. 22:55

LGWR 백그라운드 프로세스가 수행되는 경우

1. 커밋을 수행할 경우 발생

2. DBWR 백그라운드 프로세스가 데이터 버퍼 캐쉬의 변경된 데이터 블록을 데이터 파일에 적용하기 전에 발생

3. 리두 로그 버퍼의 1/3 이상이 사용되었을 경우 발생

4. 1MB 이상의 리두 로그가 생성되었을 경우 발생

5. 3초마다 발생

곰돌곰둘 Oracle_DB_Unix admin/미분류

DBWR의 활동주기

2015. 8. 16. 22:41

DBWR의 활동주기


1) 체크포인트가 발생했을 경우

2) 더티 버퍼의 수가 임계치에 도달했을 경우

3) 프리 버퍼가 필요하여 데이터 버퍼 캐쉬에서 일정한 수의 버퍼를 검색하고도 프리 버퍼를 찾지 못했을 경우

4) 테이블스페이스가 오프라인 또는 읽기 전용 (Read Only) 모드로 변경될 경우

5) 테이블이 DROP되거나 TRUNCATE될 경우

6) 테이블스페이스에 온라인 백업 명령이 수행될 경우

7) 주기적인 타임아웃에 의해 발생

곰돌곰둘 Oracle_DB_Unix admin/미분류