운영관리

CUBRID LOCK 관련 오류(ERROR CODE = -75) 정리

by 정만영 posted Dec 01, 2009

"Time: Thu Feb 09 11:31:18 2006 - ERROR *** ERROR CODE = -75, Tran = 2 Your transaction (index 2, cubrid@dgen-uau1|3092) timed out waiting on  X_LOCK lock on instance 1|28705|2 of class tn_board. You are waiting for user(s)  to finish."

메세지는 트랙재션 처리 중 lock 점유 관련된 메세지로 tn_board class 의 1|28705|2 instance 에 X_LOCK(write lock)을 누군가가 선점하고 있어, 선점된 X_LOCK 이 풀리기를(해당 점유자의 트랜잭션 종료) 기다리다가 time out 이 발생하여, 질의 수행이 취소되었다는 것입니다.
즉, 현재 instance(record) 에 update,delete 를 수행하고자 했는데 누군가가 lock 을 잡고있어서 기다리다가 lock_timeout_in_secs(lock 이 풀리기를 기다라는 시간, cubrid.conf 에 설정되어 있음) 설정값을 초과하여 에러발생한 것입니다.
일반적으로 transaction 의 수행이 오래걸려 lock 을 오래잡고있는 경우 발생하며 update 나 delete 등의 변경 작업에 바로 commit/rollback 이 수행되는지를 확인하시면 됩니다. 특별한 경우가 아니면 작업후 바로 transaction 을 종료시켜야 합니다. update, delete 질의의 속도와도 연관이 있습니다. 질의수행이 느리면 그만큼 lock 을 오래잡고 있는 것이고, 해당질의를 select 로 변경하여 속도를 확인하시고 필요하다면 질의튜닝을 하시면 됩니다.
정리하면 tn_board 테이블에 입력/수정/삭제 등의 트랜잭션을 처리하고자 할 때 같은 row에 대해 먼저 LOCK를 잡고 있는 트랜잭션이 있었고, 그 트랜잭션이 종료되기를 기다리다가 지정한 타임아웃 값 동안 획득하지 못하고 해당 트랜잭션이 종료된 상황입니다.

데이터베이스에 대한 현재 Locking 상태를 확인할 수 있는데, Lock에 대한 객체 생성(객체단위 : 테이블, 테이블의 ROW)과 각 객체별 정보를 출력할 수 있습니다.
1, lockdb 명령어로 데이터베이스에 대한 Locking 상태의 현재 스냅샷 확인.
 % cubrid lockdb   [OPTION]   database-name
 Options:  -o
출력을 파일로 저장
 % cubrid lockdb demodb

2, lockdb 정보 출력 로그분석 방법
- 서버에 접속중인 클라이언트 정보.
Transaction (index  0, unknown, unknown@unknown|-1)
Isolation SERIALIZABLE
State TRAN_ACTIVE
Timeout_period -1
-> Lock정보를 요청한 클라이언트(lockdb를 수행한 자신)
Transaction (index  1, csql, JANUS@MYCOM|3908)
Isolation REPEATABLE CLASSES AND READ UNCOMMITTED INSTANCES
State TRAN_ACTIVE
Timeout_period -1
-> 트랜잭션 번호, 프로그램, 사용자ID, 호스트명, ProcessID 자신의 isolation level, 트랜잭션 상태, 트랜잭션의 Timeout

- Lock객체별로 출력정보.
OID =  1|   332|  35
 객체의 OID(Object ID)
Object type: class = game.
 game테이블에 Lock이 선점
Total mode of holders =    IX_LOCK, Total mode of waiters = NULL_LOCK.
 game테이블에 IX_LOCK이 존재하며 높은 수준의 Lock요청 없음
Num holders =  1, Num blocked-holders=  0, Num waiters=  1
 game테이블에 Lock을 획득한 트랜잭션 1개가 있으며, 이 선점된 lock을 기다리는 트랜잭션이 1개 존재
LOCK HOLDERS:
    Tran_index =   2, Granted_mode =   X_LOCK, Count =   5, Nsubgranules =  0
 game테이블에 트랜잭션 2번이 5개의 Row에 대하여 X_LOCK을 선점
LOCK WAITERS:
    Tran_index =   1, Blocked_mode =  IX_LOCK
                      Start_waiting_at = Wed Jun 1 23:26:16 2009
                      Wait_for_nsecs = -1
 ‘Num waiters=  1’에서 대기하고 있는 lock을 징보

마지막으로 transaction commit/rollback 이 오랜시간 동안 수행하지 않을 경우 트랜잭션 강제종료할 필요가 있는데 방법은 아래와 같습니다.
1, 트랜잭션 확인.
% cubrid killtran demodb
Tran index      User name      Host name      Process id      Program name
-------------------------------------------------------------------------------------------------------------------------
      1(+)                   janus          MYCOM              3304                   cub_cas
      2(+)             Administ          MYCOM              4507                         csql
-------------------------------------------------------------------------------------------------------------------------
2, 문제 트랜잭션 강제 종료
% cubrid killtran –i 1 demodb
CUBRID 2008 R1.4
Ready to kill the following transactions:
Tran index      User name      Host name      Process id      Program name
------------------------------------------------------------------------------------------------------------------------
      1(+)                   janus          MYCOM              3304                   cub_cas
-----------------------------------------------------------------------------------------------------------------------
Do you wish to proceed ? (Y/N)y
Killing transaction associated with transaction index 1


Articles

4 5 6 7 8 9 10 11 12 13