성능 문제 SQL Server의 커서를 통해 (AN 대신 트리거의 사용)보기를 업데이트 할 때 2005

Question

나는 갱신 트리거 U이 정의 된 데이터베이스 D1에서보기 V이 그 업데이트 세 개의 테이블 T1, T2 및 T3 데이터베이스 D2. 이 세 테이블은 0.75, 6.0 &450 만 개의 레코드를 포함합니다. SQL Server 버전은 Developer Edition 9.0.3042입니다. 나는 위의보기에서 다음 업데이트 문을 수행 할 때

그것이 두 번째 내에서 준비 : 내가 걸리는 다음 배치를 발행 할 때

UPDATE V 
SET cust_task_id = 11975628 
WHERE custno = '0319607' 

그러나 일분 12 초 완료 :

DECLARE CURSOR c 
FOR SELECT custno, cust_task_id FROM V WHERE custno = '0319607' 
FOR UPDATE OF cust_task_id 

OPEN c 
    FETCH NEXT FROM c 

    UPDATE V 
    SET cust_task_id = 11975628 
    WHERE CURRENT OF c  
CLOSE c 
DEALLOCATE c 

SQL Server 2000 (8.0.2039, Standard Edition) 2000 버전에서 동일한 데이터베이스 (정의 및 레코드 수와 관련하여)와 동일한 업데이트 문을 사용하면 두 배치가 모두 1 초 이내에 반환됩니다!

당신은 당신이 2000 년 계획은 인덱스가 추구 사용하는 반면 2005 년 계획이 테이블 T1, T2 및 T3에 인덱스 스캔을 사용하고 있음을 알는 SQL 서버의 두 가지 버전의 커서 배치의 쿼리 계획을 볼 때. 그래서 그것은 성능 차이를 설명합니다.

2005 년 데이터베이스에서 sp_updatestats을 시도했지만 도움이되지 않았습니다.

아무에게도 어떻게하면 2005 년 커서 배치를 가져 와서 어떻게해야하는지 알 수 있습니까 ??

시간을내어이 문제를 조사해 주셔서 감사합니다.

인사말,

렉스 베어벡

Answer 1

당신은 2005 버전 대 2000 버전에 대한 스키마에 DIFF을 수행하게한다. 2005 년 버전 대신 추구의 스캔되는 경우

Answer 2

은 즉각적인 문제를 해결하기 위해 당신의 VIEW 생성하는 데 사용되는 목공 열 중 하나에 인덱스를 누락 될 수 있습니다처럼

, 그것은 소리, 우리는 비슷한 문제가 있었다 SQL 2000에서는 커서 루프 중에 수정 된 데이터 소스를 사용하여 커서를 이전에 사용했습니다 (이 경우 V에서 선택하고 V를 업데이트합니다). 메모리에서 (그리고 이것에 대한 확인을하는 것이 좋을 것입니다.) 커서에 대한 데이터 소스가 업데이트되었거나 다시 생성되어 변경된 내용으로 데이터 소스를 최신 상태로 유지합니다.

우리의 해결책은 먼저 임시 테이블이나 테이블 변수에 데이터를 선택하고이를 커서의 소스로 사용하는 것이 었습니다. 물론 ID 나 기타 고유 한 식별자를 사용하여 업데이트 할 SQL 코드를 수정해야하지만 시스템에 이러한 제약 조건이 있다고 가정합니다.

물론 일반적으로 솔루션 최적화를위한 약간의 공간이있는 것처럼 들리지만 커서는 일반적으로 선호되는 접근 방식이 아닙니다. 그러나 위의 내용은 성능에 대한 허용 가능한 수준까지 도달 할 수 있습니다. 적어도 지금은.