2014-12-12 5 views
0

내 데이터베이스 (db2 v9.1)의 AIX 6.1에서 동일한 테이블에 SELECT 및 및 UPDATE의 네 가지 다른 서비스가 있고 큰 테이블이 아닌 약 300,000 개의 레코드가 있습니다. 네 가지 서비스 작업이 병렬 방식으로 실행되며 각 서비스는 순차적 방식 (병렬이 아님)으로 실행됩니다. 매일 매일 끔찍한 교착 상태 문제에 직면하게되면 DB는 약 5 ~ 10 분 동안 정지 한 다음 정상적인 성능으로 돌아갑니다. 내 서비스는 절대로 SELECT 또는 UPDATE 같은 행에 동기화되어 교착 상태가 발생해도 테이블 수준이 아닌 행 수준에 있다고 생각됩니다. 또한, 내 SELECT 쿼리에서 내가 사용하는, 읽기 전용으로 행을 잠그지 않는 것을 의미하는 db2 v9.1에서는 업데이트가 수행되지 않습니다 (UR = 커밋되지 않은 읽기). 무슨 일이 일어나고 있는지에 대한 아이디어와 그 이유는 무엇입니까?db2 V9.1 교착 상태

+0

을'UR'가 함께 않습니다 * * 의미하지 SELECT 문이 잠금을 유지하지 않을 것입니다! 'WITH UR'은 다른 트랜잭션의 잠금을 읽으려는 것을 의미합니다. –

+0

@IanBjorhovde - 실제로 UR 격리 수준 _does_은 SELECT가 데이터에 아무런 잠금도 걸리지 않는다는 것을 의미합니다. – mustaccio

+0

자, 잠금 대기는 왜 그렇게 많은 시간이 걸릴까요? 내 응용 프로그램의 모든 쿼리가 같은 행을 읽거나 업데이트하지 못하도록하는 일반적인 행동입니다. – sheckoo90

답변

0

우선 교착 상태가 아닙니다. 충돌 트랜잭션 중 하나를 롤백하여 몇 초 내에 교착 상태가 DB2에 의해 해결됩니다. 귀하가 겪고있는 것이 가장 많은 잠금 대기입니다.

상황에 따라 잠금이 발생할 때이를 모니터링해야합니다. db2pd 유틸리티를 사용할 수 있습니다 (예 :

db2pd -d mydb -locks showlocks 

또는

는 는

또한 스냅 샷 모니터를 사용할 수 있습니다

db2pd -d mydb -locks wait 
:

db2 update monitor switches using statement on lock on 
db2 get snapshot for locks on mydb 

또는 스냅 샷보기 :

select * from sysibmadm.locks_held 
select * from sysibmadm.lockwaits 
+0

자, 잠금 대기는 왜 그렇게 많은 시간이 걸릴까요? 내 응용 프로그램의 모든 쿼리가 같은 행을 읽거나 업데이트하지 못하도록하는 일반적인 행동입니다. – sheckoo90

+0

문제는 다음과 같습니다. 문제가 발생하면 거의 동시에 발생하는 것으로 나타났습니다. 예를 들어 01:02, 03:03에서 03:08까지 등등. 유선이지만 사실. 또한 서버 또는 모니터링 작업에 예약 된 작업이 있는지 확인했지만 실제로 발견되지 않았습니다. – sheckoo90

+0

내가 제안한 방법은 모든 질문에 대답해야합니다. – mustaccio