Oracle ITL 교착 상태 식별 및 해결

Question

ITL (관심있는 트랜잭션 목록) 교착 상태를 일상적으로 일으키는 Oracle DB 패키지가 있습니다. 추적 파일의 관련 부분은 다음과 같습니다.

Deadlock graph: 
         ---------Blocker(s)-------- ---------Waiter(s)--------- 
Resource Name   process session holds waits process session holds waits 
TM-0000cb52-00000000  22  131   S  23  143   SS 
TM-0000ceec-00000000  23  143 SX    32  138 SX SSX 
TM-0000cb52-00000000  30  138 SX    22  131   S 
session 131: DID 0001-0016-00000D1C session 143: DID 0001-0017-000055D5 
session 143: DID 0001-0017-000055D5 session 138: DID 0001-001E-000067A0 
session 138: DID 0001-001E-000067A0 session 131: DID 0001-0016-00000D1C 
Rows waited on: 
Session 143: no row 
Session 138: no row 
Session 131: no row 

이 테이블에는 비트 맵 인덱스가 없으므로 그 원인이 아닙니다. 내가 말할 수있는 한, Waiter wait 열의 "S"를 더한 "Rows waiting on"부족은 ITL 교착 상태임을 나타냅니다. 또한, 테이블은 꽤 자주 (약 8 개의 인서트 또는 업데이트를 동시에 수행하며, 분당 240 회까지) 작성되기 때문에 ITL 교착 상태가 발생할 가능성이 높습니다.

테이블의 INITRANS 매개 변수를 늘리고 인덱스를 100으로 늘리고 테이블의 PCT_FREE를 10에서 20으로 늘린 다음 (인덱스를 다시 작성) 교착 상태가 여전히 발생합니다. 교착 상태는 업데이트하는 동안 가장 자주 발생하는 것으로 보입니다.하지만 우연의 일치 일 수 있습니다. 단 두 번 추적했을 때만입니다.

내 질문은 두 가지입니다 :
1) 이것이 실제로 ITL 교착 상태입니까?
2) ITL 교착 상태 인 경우이를 피하려면 어떻게해야합니까?

---

이것은 ITL 교착 상태 문제가 아니라 인덱스되지 않은 외래 키 문제입니다. dpbradley의 대답 덕분에 ITL 문제가 아니며 "행이없는"교착 상태의 원인을 알아 냈습니다.

select event, total_waits, time_waited, average_wait 
from v$system_event 
where event like 'enq: TX%' 
order by 2 desc; 

는 TX 경합 대기를 나타내고,

select OBJECT_NAME, SUBOBJECT_NAME, TABLESPACE_NAME, 
     OBJECT_TYPE, STATISTIC_NAME, VALUE 
    from v$segment_statistics 
    where statistic_name = 'ITL waits' 
    and value > 0 
    order by value desc; 

관련된 테이블과 인덱스를 나타낸다 :

Answer 1

ITL 압력의 최상의 표시 성능 뷰에서이다.

(모든 v$ 뷰와 마찬가지로, 결과는 인스턴스가 시작된 시점부터입니다.)

이 당신이 정말로 다음 INITRANS와 PCTFREE 매개 변수는 주 노브는, ITL은 대기가 않음을 표시하는 경우 돌아서는데 (그러나 INITRANS = 100은 나에게 꽤 높게 들린다. 그리고 이것들은 공간을 소비한다).

ITL 대기가 문제가되지 않으면 응용 프로그램 코드를 검사해야합니다.

Answer 2

가장 좋은 방법은 필요에 따라 늘리는 것입니다 (기본값 10에서 10 씩 증가). ITL 대기 시간 감소가 확인되면 설정됩니다. 일반적으로 이러한 관련 매개 변수는 Oracle 및 SQL Server에서 시행 착오에 의해 조정됩니다. 실시간으로 이러한 매개 변수를 조정하는 것은 리소스가 극도로 바쁜 경우가 아니면 큰 문제가되지 않습니다.

SELECT t.OWNER, t.OBJECT_NAME, t.OBJECT_TYPE, t.STATISTIC_NAME, t.VALUE 
    FROM v$segment_statistics t 
    WHERE t.STATISTIC_NAME = 'ITL waits' AND t.VALUE > 0 
    ORDER BY t.value desc; 

우리는이 방법을 사용하여 대기하는 때문에 ITL 오라클의 교착 상태 시나리오에 대한 몇 가지 튜닝을 수행 한 다음 ITL 멀리 이동 중 대기 또는 매우 감소되어있는 경우에는, 각 증가 후에 보려면 다음 쿼리를 사용할 수 있습니다. 참고 : initrans가 인덱스 용으로 수정 된 경우 인덱스가 다시 작성되었는지 확인하십시오. 또한 통계가 부실하지 않도록하십시오.

SQL Tuning Advisor를 사용하면 쿼리/인덱스 및 통계의 전체 상태를 볼 수 있습니다.