차이

문서의 선택한 두 판 사이의 차이를 보여줍니다.

--- study:oracle:adv_owi_10g:transaction_wait_event [2009/08/11 13:09]
starlits
+++ study:oracle:adv_owi_10g:transaction_wait_event [2009/08/17 09:39] (현재)
starlits
@@ 줄 3: / 줄 3: @@
 ===== 트랜잭션 작업순서 =====
-  * 사용자 DML(트랜잭션)수행 작업순서
+== 사용자 DML(트랜잭션)수행 작업순서 ==
 ^ 순서 ^ 작업내용 ^ 실패시 동작 ^ 이벤트 ^
@@ 줄 78: / 줄 78: @@
   - TX락은 트랜잭션을 보호하는 것이므로, 트랜잭션이 종료될때(commit or rollback) 해제된다.
+  - 여기서는 3가지 종류를 이야기 한다.
+    - enq:TX - row lock contention
+    - enq:TX - allocate ITL Entry
+    - enq:TX - index contention
+===  ===
+^ 여러 세션이 동일 로우를 변경하는 경우  | enq:TX - row lock contention  |
+^ 여러 세센이 Unique Key 충돌을 일으키는 경우  | enq:TX - row lock contention  |
+^ ITL Entry 부족  | enq:TX - allocate ITL Entry  |
+^ 여러 세션이 Bitmap Index 충돌을 일어키는 경우  | enq:TX - row lock contention   |
+^ 인덱스 리프 노드에서 Split이 발생하는 경우  | enq:TX - index contention  |
+^ 기타  | enq: Tx - contention  |
 ==== 여러 세션이 동일 로우를 변경하는 경우 ====
-  -
+  - 동일 row 변경은 TX 락 경합이 발생하는 가장 보편적인 경우이다.
+  - row level lock 구성 : **[로우 자체의 변경사실 + ITL + 트랜잭션 테이블 슬롯 + TX락]**
+  - **enq:TX - row lock contention 이벤트**
+    * 프로세스가 특정 로우를 변경하기 위해 해당 로우를 방문했을 때, \\ 현재 로우가 변경된 상태라면 ITL로부터 해당 로우를 변경한 트랙잭션을 확인하고 \\ 자기 자신을 TX Enqueue 목록에 추가하고 대기하는 이벤트
 ==== 여러 세센이 Unique Key 충돌을 일으키는 경우 ====
+  - Unique Key, Primary Key 충돌시에도 TX 락 경합이 발생한다.
+  - **enq:TX - row lock contention**
+    - 프로세스 A가 Insert를 수행한 후, \\ 프로세스 B가 Unique Key 충돌이 발생하게끔 insert를 수행하면 \\ **프로세스 B는 프로세스 A의 트랜잭션에 대해 TX 락을 Shared Mode로 획득하기 위해서 대기**한다.
+    - 프로세스 B는 프로세스 A가 commit 또는 rollback 할때까지 대기한다.
+    - 프로세스 A가 **commit** 이 이루어지면 **ORA-0001 에러** 상황이 되며, \\ **rollback** 이 이루어지면 프로세스 B의 **Insert는 성공적으로** 이루어지게 된다.
 ==== ITL Entry 부족 ====
+  - 모든 트랜잭션은 블록을 변경시키기 전에 블록 헤더의 ITL에 엔트리를 등록해야 한다.
+  - **enq:TX - allocate ITL entry**
+    - ITL 이 MAXTRANS를 초과하거나 블록 내의 여유공간이 부족해서 엔트리를 등록하는 것이 불가능한 경우, \\ 프로세스는 이미 ITL에 엔트리를 등록한 프레세스의 트랜잭션에 대해 TX 락을 Shared mode로 획득하기 위해 대기하는 이벤트
+  - 10g 부터는 MAXTRANS 값이 255로 고정되어 있다.
 ==== 여러 세션이 Bitmap Index 충돌을 일어키는 경우 ====
-  -
+  - 하나의 리프 노드가 넓은 범위의 ROWID를 관리한다.
+  - **enq:TX - row lock contention**
+    - 테이블의 로우가 변경될때마다 비트맵 인덱스에 해당하는 컬럼값에 대해 로우가 속한 리프 노드의 비트맵을 매번 새로 계산해주어야 한다. \\ 따라서 동시에 두 세션이 같은 리프 노드의 비트맵 연산을 수행할 경우, 순서를 보장하기 위해서 TX 락을 획득한다.
+    - 특정 세션이 TX 락을 Exclusive 하게 획득한 후, 비트맵 연산을 수행하고 아직 커밋을 하지 않았다면, \\ 다른 세션들은 선행한 트랜잭션에 대해 TX 락을 Shared mode로 확보하기 위해 대기함으로써 비트맵 연산이 끝나기를 기다리게 된다. 즉, 하나의 리프 노드가 넒은 범위의 ROWID를 관리하기 때문에 TX 락 경합이 광범위하게 나타날 수 있다.
 ==== 인덱스 리프 노드에서 Split이 발생하는 경우 ====
-  -
+  - 비트리 인덱스는 **데이터를 추가하는 과정에서 리프 노드가 꽉차면 Split을 함으로써 Balance를 맞춘다.**
+  - **enq:TX - index contention**
+    - 보통의 상황에서는 잘 볼생하지 않는다.
+    - 동시에 여러 세션에서 인덱스가 생성되어 있는 테이블에 대해서 많은 양의 DML을 수행하는 경우에 주로 발생한다.
+    - 시퀀스 등을 사용해서 값을 생성하는 컬럼에 대해 인덱스가 생성되는 경우
+    - 인덱스가 생성되어 있지 않은 테이블을 변경하는 경우
+    - 테이블에 LOB컬럼이 있을때 동시에 여러세션이 LOB테이블을 변경하는 경우
 ==== 기타(enq: Tx - contention) ====
-  -
+  - **enq:TX - contention**
+    - Distributed Transaction(분산 트랜잭션) 환경에서 Prepared Transaction에 의해 락이 획득된 로우를 읽는 경우 \\ 트랜잭션이 종료(commit,rollback,in-doubt)될때까지 TX락을 Shared Mode로 획득하기 위해서 대기한다.
+    - FLM을 세그멘트 공간관리기법으로 사용하는 경우, \\ TFL(Transaction FreeList)을 확보하려는 프로세스는 TFL을 확보하지 못할 경우 \\ 이미 TFL을 확보한 Transaction의 TX락을 Shared Mode로 확보하기 위해서 대기한다.
+    - 언두 세그먼트 헤더의 트랜잭션 테이블에서 새로운 슬롯을 할당받고자 하는 경우 \\ TX락을 Exclusive 하게 획득한다.
+  - 이들 경우는 겨의 보고되지 않고 있으며, 성능상 이슈도 없는 것으로 보인다.
+=== 동시에 많은 수의 트랜잭션이 발생할 경우 enq:TX - contention 이벤트 대기현상 문제가 생길 수 있다.  ===
 ===== enq:UL - contention, PL/SQL lock Timer =====

adminschool.net wiki

사용자 도구

사이트 도구

차이

문서 도구