명백한 이유없이 SQL Server에서 DELETE 문이 멈 춥니 다.

Question

을 편집하십시오. 해결 : 테이블에 루프가있는 방아쇠가 있습니다 (내 대답은 아래 참조).

DELETE FROM tablename WHERE pk = 12345 

이 그냥 달려, 아니 시간 제한, 아니 아무것도 :

---

우리는 다음과 같습니다 기본 삭제 문이있다.

우리는 실행 계획을 살펴 봤으며 외래 키가 삭제되지 않도록 관련 테이블에 대한 많은 조회로 구성되어 있지만 다른 테이블에는 해당 테이블을 참조하는 행이 없음을 확인했습니다 특정 행.

현재 데이터베이스에 연결된 다른 사용자가 없습니다.

DBCC CHECKDB를 실행하여 오류가보고되었습니다.

sp_who 및 sp_lock 쿼리가 걸려있는 동안의 결과를 보면, 나는 내 SPID가 PAG 및 키 잠금을 충분히뿐만 아니라 가끔 TAB 잠금이있는 것을 알 수 있습니다.

테이블에 1.777.621 개의 행이 있습니다. 예, pk가 기본 키이므로 인덱스를 기준으로 한 단일 행 삭제입니다. 테이블 스풀 (열망 스풀)이 있지만 예상 행 개수는 1입니다. 실제로이 테이블 스캔이 위장 할 수 있습니까? 기본 키 열을 봅니다.

테이블에서 DBCC DBREINDEX 및 UPDATE STATISTICS를 시도했습니다. 모두 합리적인 시간 내에 완료되었습니다.

불행히도이 특정 테이블에는 많은 수의 인덱스가 있습니다. 우리 시스템의 핵심 테이블이며 많은 칼럼과 참고 자료 (발신과 수신)가 있습니다. 정확한 수는 48 개의 인덱스 + 기본 키 클러스터 인덱스입니다.

다른 어떤 조치를 취해야합니까?

이 테이블에는 이전에이 문제가 없었 음을 알 수 있습니다.이 문제는 오늘 갑자기 발생합니다. 우리는 또한 동일한 테이블 설정 (고객 데이터베이스의 사본)을 가진 많은 데이터베이스를 보유하고 있으며 예상대로 작동합니다. 문제가있는 것입니다.

Answer 1

한 조각은 당신의 데이터를 삭제하는 테이블에 인덱스의 수입니다. SQL Server는 모든 인덱스에서 기본 키를 포인터로 사용하므로 기본 인덱스를 변경하려면 모든 인덱스를 업데이트해야합니다. 비록 우리가 높은 숫자를 말하지 않는다면, 이것은 문제가되어서는 안됩니다.

FK 관계의 다른 많은 테이블에서 참조하는 데이터베이스의 기본 테이블이라고 추측합니다. 이것은 참조를 위해 나머지 테이블을 검사 할 때 많은 수의 잠금을 설명합니다.그리고 계단식 삭제 기능이 켜져 있다면 테이블 A에서 삭제로 이어질 수 있습니다.

Answer 2

해당 테이블에서 색인을 다시 만들고 통계를 재생성 해보십시오. 누락 된 정보의

DBCC REINDEX

UPDATE STATISTICS

Answer 3

좋아, 이것은 당황 스럽다.

동료가 얼마전에 해당 테이블에 트리거를 추가했으며 트리거에 버그가있었습니다. 그는 버그를 고쳤지 만 그 테이블에 대한 방아쇠는 결코 다시 만들어지지 않았습니다.

서버가 실제로 아무 것도하지 않았으므로 방대한 양의 시간을 보냈습니다.

아 글쎄

... 이것을 읽고 문제를 숙고 사람의 시선에 대한

감사합니다.

저는 Josef의 대답이 가장 가까웠으므로이를 받아 들일 것입니다. 간접적 인 삭제로 인해 간접적으로 문제가 발생했습니다.