동일한 (?) SQL Server 2005 시스템; 쿼리는 한 쪽에서 2 초, 다른 쪽에서는 15 분

환경 :

SQL Server 2005를 실행하는 두 개의 32 비트 Windows Server 2003 R2 시스템이 있습니다. 하드웨어 구성은 Xeon 5160 CPU, 4GB RAM 및 13GB RAID0를 가진 동일한 서버입니다. AWE 및 / 3GB 플래그가 활성화되어 있지 않습니다.

서버는 사전 정의 된 설치 점검 목록을 사용하여 나란히 설정되었으며 설치된 모든 소프트웨어는 두 시스템에서 동일합니다.

우리가 확인하는 모든 SQL Server 설치 설정과 패치 수준은 동일합니다. 한 가지 차이점은 TEMPDB가 빠른 시스템에서 400MB이고 느린 시스템에서 1.2GB라는 것입니다. 그러나 두 경우 모두 TEMPDB 할당이 발생하지 않습니다.

문제 :

저장 프로시 저는 한 쪽에서 2 초 안에 실행되지만 다른 쪽에서는 15 분 안에 실행됩니다. 추가 15 분 동안 디스크 작업이 거의 없거나 메모리 사용량이 변경되지 않지만 한 CPU 코어가 전체 시간에 100 %로 고정됩니다.

이 동작은 데이터베이스가 한 데이터베이스에서 백업되고 다른 데이터베이스로 복원 된 경우에도 지속됩니다.

이 저장 프로 시저이기 때문에, 활동 모니터와 프로파일 러는 우리에게 대한 세부 사항이 표시되지 않는 경우 저장 프로 시저이 높은 CPU 활동이 발생하고 있습니다.

질문:

우리는 무엇을 더 살펴 봐야합니까?

후속 조치 :

다음 커서 정의에 대한 FETCH NEXT 문에서 느림이 발생합니다.

DECLARE C CURSOR FOR
    SELECT X, Y
    FROM dbo.A
    WHERE X NOT IN (SELECT X FROM dbo.B)
    AND Z <=0
...
<snip>
...
FETCH NEXT FROM C INTO @X, @Y
FETCH NEXT FROM C INTO @X, @Y
...

약 1000 개의 행만 포함하는 테이블의 각 FETCH 문에는 약 7.25 분이 필요합니다. (아니요, 왜 두 행을 계속하는지 개발자에게 물어볼 필요는 없지만 두 서버에서 올바르게 실행됩니다).

Virtual Reads가 실제로 높은 것처럼 보이기 때문에 "NOT IN (SELECT ...)"에 대해서는 조금 의심이됩니다.

대기 및 대기열 과 같은 성능 문제 해결 방법을 사용하면 CPU 소비가 높은 이유를 파악할 수 있으며 병목 현상이 확인되면 적절한 조치를 취하는 것이 좋습니다.

SQL Server는 다른 상자에서 다른 계획을 선택하고 있습니다.

복원은 일반적으로 통계에 따라 문제를 제거하므로 서버 차이점을 살펴 보겠습니다.

일부 거친 점검이 먼저 이루어집니다. 가정하지 마십시오 : 확인

• sys.configuration 에서 SQL Server 설정이 동일한 지 확인하십시오 ( 예 : Max degree 또는 parallelism)
• DBCC USEROPTIONS를 실행하여 런타임에 ANSI 설정이 다른지 확인하십시오 (ANS 설정이 선택한 계획에 영향을 줄 수 있음)
• Windows 및 SQL Server 로그를 확인하여 문제가 있는지 확인하십시오.

그런 다음 Remus의 답변에 따라 깊은 곳에서 뛰어 내립니다.

다른 모든 것이 동일하면 (@gbn의 답변에 따라) 각 서버에서 다른 실행 계획이 생성 될 수 있습니다. 학문적으로 두 계획을보고 각 서버의 계획 캐시에서 가져 와서 가능한 경우 질문에 추가하는 것이 흥미로울 것입니다. 그런 다음 성능에 큰 변화를 일으키는 계획의 차이점을 식별 할 수 있습니다.

빠른 수정을 위해 USE PLAN 힌트를 살펴보십시오 . 이를 통해 빠른 서버에서 느린 서버의 저장 프로 시저로 양호한 계획을 첨부 할 수 있습니다.

편집 : 업데이트 다시 따라 : 커서

다른 답변에서 언급되지 않은 다른 검색어의 변형 :

DECLARE C CURSOR FOR
    SELECT X, Y
    FROM dbo.A
    WHERE NOT EXISTS (SELECT 1 FROM dbo.B WHERE dbo.B.X = dbo.A.X)
    AND Z <=0
...
<snip>
...
FETCH NEXT FROM C INTO @X, @Y
FETCH NEXT FROM C INTO @X, @Y

유머러스하고 교체해보십시오.

DECLARE C CURSOR FOR
SELECT X, Y
FROM dbo.A
WHERE X NOT IN (SELECT X FROM dbo.B)
AND Z <=0

이것으로 :

DECLARE C CURSOR FOR
SELECT 
    X, 
    Y
FROM dbo.A

    LEFT OUTER JOIN dbo.B
        ON dbo.A.X = dbo.b.X

WHERE dbo.B.X IS NULL
AND Z <=0

이것이 코드의 FETCH NEXT FROM 부분에서 성능 문제로 나타나야한다고 생각하지는 않지만 아직 카페인 주입을하지 않았습니다. 내 제안을 시도하고 알려주십시오.

도움이 되었기를 바랍니다,

매트

색인을 확인하고 모든 통계를 업데이트하십시오. 나는 매우 간결한 문제를 겪었고 한 컴퓨터의 통계가 기이 한 것으로 판명되었습니다.

나는이 같은 행동을 두 번 경험했으며 매번 수정 한 것을 알려 드리겠습니다.

1.) 캐시 된 계획이 끔찍했기 때문에 WITH RECOMPILE 힌트를 저장 프로 시저에 추가했습니다.

2.) 테이블 변수 대신 임시 테이블을 사용하도록 저장 프로 시저를 변경했습니다.

도움이 되길 바랍니다. 행운을 빕니다.