DB2 교착 상태 해결 프로세스의 전체 기록

DB2는 주로 대규모 애플리케이션 시스템에 사용되며 확장성이 뛰어나고 메인프레임부터 단일 사용자 환경까지 모든 것을 지원할 수 있습니다. DB2는 높은 수준의 데이터 활용도, 무결성, 보안 및 복구 가능성을 제공합니다. 이번 글에서는 주로 DB2 교착상태 해결 과정의 전체 기록을 소개한다. 이 글에서 발생하는 교착상태는 처리 과정이 꽤 까다롭다. 필요한 친구들은 참고하면 된다.

실제 환경에서 사용하는 데이터베이스 DB2입니다. 그런데 최근 이상한 교착상태 현상이 빈번하게 나타나고 있다. 특정 select sql문이 항상 교착상태에 빠지는 것이다.

과거 경험에 따르면 업데이트/삭제 등의 업데이트 SQL 문은 일반적으로 교착 상태 문제를 발생시킵니다. 그리고 이 select sql 문은 대규모 데이터 처리가 없는 매우 일반적인 SQL입니다.

이 교착 상태를 분석해 보면 해결하기 어려운 점이 많습니다.

1. 프로덕션 환경의 데이터 양이 많기 때문에 프로덕션 환경의 연관 테이블 데이터를 테스트 환경으로 가져올 수 없습니다. 즉, 데이터의 양을 시뮬레이션할 수 없습니다.
2. 로그 출력이 없습니다. 프로덕션 환경의 로그 출력 수준이 ERROR이기 때문입니다.
3. 고객이 허용하지 않아 프로덕션 환경에서 테스트할 수 없습니다.
4. 프로덕션 환경의 데이터베이스에서는 스냅샷 및 기타 기능을 활성화할 수 없습니다. 성능에 영향을 미치기 때문입니다.

상상하실 수 있듯이 스냅샷과 같은 기능이 없으면 교착 상태 분석은 코드 분석에만 의존할 수 있습니다. 하지만 이 과정은 매우 복잡하고, 코드를 분석하는 것만으로는 단서가 없습니다.

1단계: 데이터의 양 때문인 것으로 의심됩니다.

프로덕션 환경의 데이터 양이 매우 많기 때문에 이 처리에는 다른 많은 테이블도 처리됩니다. 그렇다면 대량의 데이터로 인해 시스템에 과부하가 걸려 교착 상태가 발생한 것은 아닌지 궁금합니다.
그래서 교착상태가 발생했을 때 CPU, 하드디스크, 네트워크 등의 부하 정보를 얻었습니다. 단서는 발견되지 않았습니다.

2단계: 테스트 프로그램을 만들고 멀티스레딩을 사용하여 테스트 환경에서 여러 사용자를 시뮬레이션하여 이 처리를 수행합니다.

개발 환경에서 이러한 교착 상태를 재현하기 위해 다중 사용자 작업을 시뮬레이션하는 다중 스레드 테스트 프로그램을 만들었습니다. 아쉽게도 아직 재현되지 않았습니다.

3단계: 테스트 환경 데이터베이스와 프로덕션 환경 데이터베이스의 차이점을 분석합니다.

이때에도 여전히 데이터 양으로 인해 문제가 발생하는 것으로 의심됩니다. 그래서 우리는 개발 환경에서도 프로덕션 환경만큼 많은 데이터를 확보하기 위해 최선을 다했습니다.
테스트를 실행한 후에도 여전히 재현이 되지 않습니다.

4단계: 사용자 작업 로그 분석

다른 해결책이 없으면 사용자 작업 로그를 분석하여 단서를 찾아야 합니다. 열심히 노력한 결과, 두 사람이 동시에 이 작업을 수행하면 기본적으로 교착 상태가 발생한다는 사실을 발견했습니다. 따라서 두 사람이 동시에 작업을 하여 문제가 발생한 것으로 판단됩니다. 그런데 왜 개발 환경에서는 많은 사람의 작업을 시뮬레이션하는데 교착 상태가 발생하지 않습니까?


5단계: 데이터베이스 설정 문제 발견

테스트 프로그램을 수정하고 시뮬레이션 사용자 수를 늘렸으나 안타깝게도 여전히 문제가 재현되지 않았습니다. 이때 우리는 개발 환경의 데이터베이스 설정이 프로덕션 환경의 데이터베이스 설정과 다른가? 두 데이터베이스의 설정을 비교한 결과 많은 매개변수가 서로 다르다는 사실을 발견했습니다. 하지만 우리는 잠금과 관련된 설정, 즉 LOCK 키워드가 포함된 설정에만 집중했습니다.

6단계: 테스트 환경 데이터베이스와 프로덕션 환경 데이터베이스의 설정을 일관되게 유지합니다.


잠금 관련 설정을 모두 프로덕션 환경과 일치하도록 변경했습니다. 그러나 여전히 교착상태는 재현되지 않습니다. 마침내 한 사람이 "cur_commit" 설정이 다르다는 것을 발견했습니다. 그래서 문서를 질의해 cur_commit의 특징을 알아냈습니다. cur_commit = false인 경우 다음 상황에서는 교착 상태가 발생합니다.
스레드 1이 데이터 A를 삽입한 다음 스레드 2가 데이터 B를 삽입합니다. 스레드 2가 트랜잭션을 제출하기 전에 스레드 1이 데이터 A를 쿼리하여 교착 상태가 발생합니다.
개발 환경에서는 cur_commit = true이므로 이 현상을 시뮬레이션할 수 없었습니다.
그래서 cur_commit을 false로 변경했습니다.


7단계: 테스트 프로그램을 사용하여 시뮬레이션


테스트 프로그램을 수정하여 위 두 스레드의 동작을 시뮬레이션하고 교착 상태를 성공적으로 재현했습니다. 오류 로그 정보도 프로덕션 환경과 일치합니다.

8단계: 화면 조작을 사용하여 시뮬레이션

그런 다음 프로그램을 수정하고 화면 조작을 사용하여 교착 상태를 성공적으로 재현했습니다.
해결책:
해결 방법은 매우 간단합니다. 즉, 쿼리 문의 조건을 인덱스로 추가하면 교착 상태가 발생하지 않습니다.
이 테이블의 데이터 용량은 크지 않기 때문에 성능에 거의 영향을 미치지 않습니다.



관련 권장사항:

db2

Python 모듈의 ibm_db 메소드 오프라인 설치에 대한 자세한 설명

DB2 데이터베이스에 대한 Python 연결

PHP를 사용하여 DB2 Express C를 작동하는 다섯 가지 방법(1)_PHP 튜토리얼

위 내용은 DB2 교착 상태 해결 프로세스의 전체 기록의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!