특정 테이블의 삽입 속도가 느린 이유를 어떻게 알 수 있습니까?

SQL 테이블의 INSERT가 여러 가지 이유로 느릴 수 있음을 알고 있습니다.

• 테이블에 INSERT TRIGGER 존재
• 검사해야하는 많은 강제 제약 조건 (일반적으로 외래 키)
• 테이블 가운데에 행이 삽입되면 클러스터형 인덱스에서 페이지가 분할 됨
• 모든 관련 비 클러스터형 인덱스 업데이트
• 테이블의 다른 활동으로부터 차단
• 잘못된 IO 쓰기 응답 시간
• ... 내가 놓친 것이 있습니까?

특정 사건에 책임이있는 사람을 어떻게 알 수 있습니까? 페이지 분할과 비 클러스터형 인덱스 업데이트의 영향을 어떻게 측정 할 수 있습니까?

임시 테이블에서 한 번에 약 10,000 행을 삽입하는 저장 프로 시저가 있는데 10k 행당 약 90 초가 걸립니다. 다른 spids가 시간 초과되기 때문에 허용 할 수 없을 정도로 느립니다.

실행 계획을 살펴본 결과 INSERT CLUSTERED INDEX 작업과 FK 조회에서 모든 INDEX SEEKS를 볼 수는 있지만 왜 그렇게 오래 걸리는지 확실하지 않습니다. 트리거는 없지만 테이블에 소수의 FKey (정확하게 색인 된 것으로 표시됨)가 있습니다.

이것은 SQL 2000 데이터베이스입니다.

당신이 볼 수있는 것들 ...

배치 크기를 10000에서 2000 또는 1000과 같이 더 작은 것으로 줄입니다 (행 크기가 얼마나 큰지 말하지 않았습니다).

FK 조회가 얼마나 많은 IO를 사용하는지 보려면 IO Stats를 켜십시오.

삽입이 발생할 때 대기 상태는 무엇입니까 (master.dbo.sysprocesses)?

여기서 시작해서 어디로 가는지 보자.

브래드,

쿼리의 대기 통계를 조사해야합니다. SQL2000에서는 DBCC SQLPERF ( "waitstats") 구문을 사용하여 세부 사항을 얻을 수 있습니다.

쿼리 성능을 분석 할 때 찾고있는 것을 말할 수 있습니다. 아마 도움이 될 것입니다.

• 쿼리 실행 계획을 분석하고 인덱스 스캔, 테이블 스캔, SQL 데이터 유형에 대한 convert_implicit 함수 사용, 병렬 처리를 점검하십시오.
• SET STATISTICS IO ON 및 SET STATISTICS TIME ON으로 쿼리를 실행하여 각 삽입에 대한 실행 시간 및 읽기 / 쓰기 IO를 확인하십시오.
• 세션 spid에 대한 sysprocesses의 대기 시간을 확인하십시오.
• 프로파일 러를 실행하고 표준 템플릿을 선택하십시오. 성능 통계 (반복 된 경우 계획이 여러 번 컴파일되면 좋지 않음), RPC : completed, SQL : batchcompleted 및 SQL : batchstarting을 선택하십시오. 열 행 수 를 추가 하여 배치의 행 수를 정확하게 확인하십시오. 결과 만 필터링하면 검색어 만 표시됩니다.
• 마지막 으로 windows perfmon에서 Page Life Expectancy 카운터를 수집 하고 300 (5 분) 미만이면 SQL 메모리가 부족합니다. 디스크 카운터 길이 (디스크 큐 길이 , 디스크 시간 (데이터 파일 드라이브), 디스크 시간 (로그 파일 드라이브)) 를 수집하여 디스크 에 압력이 있는지 확인하십시오.

다음을 사용하십시오.

SET STATISTICS IO ON

과

SET STATISTICS PROFILE ON

통계 IO

가장 많은 양의 테이블 스캔, 논리적 읽기 및 물리적 읽기를 수행하는 테이블을 알려주는 데 유용 할 수 있습니다 (이 세 가지를 사용하여 쿼리 계획의 어느 부분에서 가장 튜닝이 필요한지에 초점을 맞 춥니 다)

통계 프로파일

주로 쿼리 계획을 표 형식으로 반환하면 쿼리에서 가장 많은 비용이 드는 항목에 대한 IO 및 CPU 열을 볼 수 있습니다 (임시 테이블의 테이블 스캔과 사용자의 테이블에 삽입하는 정렬) 클러스터 키 등)