by-nc-sa     개발자, DBA가 함께 만들어가는 구루비 지식창고!

비관적 vs 낙관적 동시성 제어




03 비관적 vs. 낙관적 동시성 제어



(1) 비관적 동시성 제어


 동시성 제어를 위해 트랜잭션 고립화 수준을 변경하는 DBMS기능을 사용할 수 없는 경우가 있다.

이럴때는 개발자가 직접 구현을 해야한다.

비관적 동시성 제어(Pessimistic Concurrency Control)은 사용자들이 같은 데이터를 동시에 수정할 것이라고 가정할 때

한 사용자가 데이터를 읽는 시점에 Lock을 걸고 조회 또는 갱신 처리가 완료될 때가지 이를 유지한다

그러면 다른 사용자들은 이 트랜잭션이 완료되기 전까지는 해당 데이터를 수정할 수 없기에 비관적 동시성 제어로 인하여 동시성 제어를 받게 된다.


비관적 동시성 제어 이용시 활용법

◆ select문에 for update를 사용해서 해당 고객 레코드에 Lock을 걸어 둔다면 데이터가 잘못 갱신되는 문제를 방지한다.

◆ wait 또는 nowait옵션을 함께 사용하면 Lock을 얻기위해 무한정 기다리지 않아도 된다.

◆ wait 또는 nowait옵션을 이용하면 다른 트랜잭션에 의해 Lock이 걸렸을 때 Exception을 만나게 되므로 alert를 출력하고 트랜잭션을 종료할 수 있다.

◆ Select for update skip locked라는 기존 Locking 범위를 skip하는 옵션도  9i부터 지원되는 undocumented된 방법이며 과거부터 AQ(Advanced Queuing)기능을 위해 존재 했던 기능이기도 하다.
 

 

위의 방법들은 오히려 동시성을 증가시킬 수 있는 방법이다.

 
for update nowait -> 대기없이 Exception(ORA-00054)을 던짐

ORA-00054, 00000, "resource busy and acquire with NOWAIT specified"
// *Cause: Resource interested is busy.
// *Action: Retry if necessary.

for update wait 3 -> 3초 대기후 Exception(ORA-3006)을 던짐

ORA-30006: resource busy; acquire with WAIT timeout expired


참고

Version 필드를 통한 체크

변경하는 테이블에 변경시간을 기록하는 컬럼을 추가 하여

Select for update로 레코드 락을 걸지 않고 변경 컬럼 값만을 체크해 해당 컬럼이 변경 되었다면 update 되지 않도록 수행하는 처리 절차를 구사하여

명시적인 락을 걸지 않고도 정합성을 유지할 수 있다.

 


(2)낙관적 동시성 제어


낙관적 동시성 제어는 (Optimistic Concurrency Control ) 는 사용자들이 같은 데이터를 동시에 수정 하지 않을 것이라고 가정한다.

읽는 시점에는 Lock을 사용하지 않지만 데이터를 수정하고자 하는 시점에 앞서 읽은 데이터가 다른 사용자에 의한 변경여부를 반드시 확인해야 한다.

낙관적 동시성 제어를 사용하면 Lock이 유지되는 시간이 매우 짧아져서 동시성을 높이는데 유리하다.

낙관적 동시성 제어에도 update전에 for update nowait 문을 select절과 함께 한번 더 수행하면 다른 트랜잭션에 의해 설정된 Lock에 의한 동시성 저하를 예방할 수 있다.


select 고객번호 from 고객 where 고객번호 = :cust_num and 변경일시 = :mod_dt for update nowait;


오라클 10g부터 제공되는 Pseudo 컬럼 ora_rowscn을 활용하면 Timestamp를 오라클이 직접 관리해 주므로 쉽고 완벽하게 동시성 제어가 가능하다.

 SQL> select e.empno, e.ename
  2  , ORA_ROWSCN
  3  , SCN_TO_TIMESTAMP(ORA_ROWSCN)
  4  from emp e;
 
     EMPNO ENAME      ORA_ROWSCN SCN_TO_TIMESTAMP(ORA_ROWSCN)
------ ------ ------ --------------------------------
      7369 SMITH          529426 05/08/30 15:05:26.000000000
      7499 ALLEN          529426 05/08/30 15:05:26.000000000
      7521 WARD           529426 05/08/30 15:05:26.000000000
      7566 JONES          529426 05/08/30 15:05:26.000000000
      7654 MARTIN         529426 05/08/30 15:05:26.000000000
      7698 BLAKE          529426 05/08/30 15:05:26.000000000
      7782 CLARK          529426 05/08/30 15:05:26.000000000
      7788 SCOTT          529426 05/08/30 15:05:26.000000000
      7839 KING           529426 05/08/30 15:05:26.000000000
      7844 TURNER         529426 05/08/30 15:05:26.000000000
      7876 ADAMS          529426 05/08/30 15:05:26.000000000
      7900 JAMES          529426 05/08/30 15:05:26.000000000
      7902 FORD           529426 05/08/30 15:05:26.000000000
      7934 MILLER         529426 05/08/30 15:05:26.000000000

ora_rowscn Pseudo 컬럼을 이용하면 특정 레코드가 변경 후 커밋된 시점을 추적할 수 있다.

단 이 값을 이용해 정확한 동시성을 제어하려면 테이블을 생성할 때 아래와 같은 옵션을 사용해야 한다.

아래와 같은 옵션을 사용해야 로우 단위로 SCN을 기록하기 때문이다.


create table t ROWDEPENDENCIES nologging as select * from scott.emp;


 
기본값은 NoRowDependencies 이며 이는 블록 단위로 기록을 한다.

이는 기본값으로 설정 되어 있을때는 한블록 내에서 레코드 하나만 변경하고 커밋하더라도 블록 내 모든 레코드의 ora_rowscn이 변경된다

* ora_rowscn은 영구히 저장되는 값이지만 이는 시간정보로 변환하는 데는 정해진 기한이 있다.

SMON 프로세스는 내부적으로 SCN과 Timestamp간 매핑정보를 관리, 오라클은 이 매핑 정보(sys.smon_scn_time테이블)를 이용 scn_to_timestamp 함수를 구현했다.

그러나 이 매핑 테이블의 보관 주기는 5일 이다. 이 시간이 지나면 매핑값을 찾을 수 없기에 오류(ORA-08181)를 발생한다.

 ORA-08181  Invalid system change number specified.

단순히 동시성 제어를 위해서만 사용하면 ora_rowscn을 활용하는 것이 효과적이다.

그러나 변경 일시 정보를 다른 용도로 사용할 것이라면 기존 방식대로 구현해야 한다. 



위 사용된 Image는 마소7월호에서 발췌하였습니다.
 

문서정보

Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.
  1. 10월 28, 2009

    꼬챙이 says:

    ORA_ROWSCN For each row, ORA_ROWSCN returns the conservative upper bound system...

    ORA_ROWSCN
    For each row, ORA_ROWSCN returns the conservative upper bound system change number (SCN) of the most recent change to the row. This pseudocolumn is useful for determining approximately when a row was last updated. It is not absolutely precise, because Oracle tracks SCNs by transaction committed for the block in which the row resides. You can obtain a more fine-grained approximation of the SCN by creating your tables with row-level dependency tracking. Please refer to CREATE TABLE ... NOROWDEPENDENCIES | ROWDEPENDENCIES for more information on row-level dependency tracking.

    You cannot use this pseudocolumn in a query to a view. However, you can use it to refer to the underlying table when creating a view. You can also use this pseudocolumn in the WHERE clause of an UPDATE or DELETE statement.

    ORA_ROWSCN is not supported for Flashback Query. Instead, use the version query pseudocolumns, which are provided explicitly for Flashback Query. Please refer to the SELECT ... flashback_query_clause for information on Flashback Query and "Version Query Pseudocolumns " for additional information on those pseudocolumns.

    Restriction: This pseudocolumn is not supported for external tables.

    Example

    The first statement below uses the ORA_ROWSCN pseudocolumn to get the system change number of the last operation on the employees table. The second statement uses the pseudocolumn with the SCN_TO_TIMESTAMP function to determine the timestamp of the operation:

    SELECT ORA_ROWSCN, last_name FROM employees WHERE employee_id = 188;

    SELECT SCN_TO_TIMESTAMP(ORA_ROWSCN), last_name FROM employees
    WHERE employee_id = 188;