느린 쿼리를 조사하는 동안 실행 계획이 예외적으로 차분한 것으로 나타났습니다 (예상 실행 횟수가 1 인 경우 9 백만 건의 검색을 수행하는 중첩 루프). 실제로 구식이었던 일부 관련 통계가 통계를 재구성하고 성능 문제가 효과적으로 해결되었음을 확인했습니다.
이 데이터베이스에는 자동 업데이트 통계가 활성화되어 있습니다 (기본적으로 설정되어 있음). 20 % + 500 행 수정 (업데이트 / 삽입 / 삭제)에 기반한 자동 통계 업데이트에 대한 임계 값이 있음을 이해합니다. 이 임계 값은 여러 색인에서 크게 초과 한 것으로 보입니다. (A) 자동 업데이트에 문제가 있거나 (B) 온라인에서 찾을 수있는 것보다 업데이트 전략에 더 많은 것이 있습니다 선적 서류 비치.
예약 된 작업을 통해 통계를 업데이트 할 수 있으며 다른 솔루션을 찾을 수없는 경우 취할 수있는 접근 방법 일 가능성이 높지만 그러한 많은 수정 사항으로 인해 일부 통계에 대한 자동 업데이트-예약 된 작업으로 업데이트 할 통계를 결정하는 데 도움이되는 이유를 이해합니다.
몇 가지 추가 사항 :
1)로드 테스트에 의해 데이터가 생성되고 짧은 시간에 대량의 데이터가 추가되어 자동 업데이트가 주기적으로 (예 : 하루에 한 번) 발생하는 데이터베이스에서 문제가 발견되었습니다. 대부분) 관찰 된 동작 중 일부를 설명 할 수 있습니다. 또한 우리의로드 테스트는 데이터베이스에 많은 스트레스를주는 경향이 있으므로로드가 많은 동안 SQL이 통계 업데이트를 지연시키는 지 궁금합니다 (그리고 어떤 이유로 통계를 업데이트하지 않는지).
2) 연속 INSERT, SELECT 및 DELETE 문이 포함 된 테스트 스크립트를 사용하여이 문제를 재현하려고하면 문제가 발생하지 않았습니다. 로드 테스트 스크립트가 행을 개별적으로 삽입하는 경향이있는 반면, 여기에서 이러한 명령문이 각각의 SQL 문당 많은 행에 영향을 준다는 점이 궁금합니다.
3) 해당 DB가 'Simple'복구 모델로 설정되어 있습니다.
관련 링크 :
또한 Microsoft Connect를 통해이 문제를 제기했습니다.
2011-06-30 업데이트 :
추가 조사에서 임계 수준 (예 : 500 행 + 20 %)을 벗어난 통계는 문제 쿼리에서 사용되지 않는 통계라고 생각합니다. 따라서 쿼리가 실행될 때 아마도 업데이트 될 것입니다 그것들이 필요합니다. 통계를 위해 하는 쿼리에 의해 사용이 정기적으로 업데이트됩니다. 나머지 문제는 이러한 통계가 비교적 적은 수의 삽입 후에 (예를 들어, 위에서 언급 한 9 백만 정도를 추정하여 추정 된 숫자가 1 인 곳을 찾는) 쿼리 계획 최적화 프로그램을 잘못 오도한다는 것입니다.
이 시점에서 문제는 기본 키의 잘못된 선택과 관련이 있으며 키는 NEWID ()를 사용하여 만든 고유 식별자이므로 특히 SQL의 기본 채우기 비율로 매우 단편화 된 인덱스를 생성합니다. 서버가 100 %입니다. 제 직감으로 인해 행 삽입이 상대적으로 적은 후에 통계를 잘못 계산하여 통계를 다시 계산하기위한 임계 값보다 작습니다. 인덱스를 재 구축하지 않고 많은 양의 데이터를 생성했기 때문에 이것은 문제가 될 수 있습니다. 따라서 통계가 좋지 않으면 결과적으로 매우 높은 인덱스 조각화가 발생할 수 있습니다. 오랜 시간 동안 실제 시스템의 성능을 더 잘 이해하려면로드 테스트에 SQL Server 유지 관리주기를 추가해야한다고 생각합니다.
업데이트 2012-01-10 :
고려해야 할 또 다른 요소. 구식 및 / 또는 오해의 소지가있는 통계의 발생과 관련된 특정 단점을 해결하기 위해 SQL Server 2005에 두 개의 추적 플래그가 추가되었습니다 (2008 년에도 여전히 존재하는 것으로 나타남). 해당 플래그는 다음과 같습니다.
DBCC TRACEON(2389)
DBCC TRACEON(2390)
MSDN : Ian Jose의 WebLog : 오름차순 키 및 오름차순 열에 대한 자동 빠른 수정 통계 통계, Fabiano Amorim
물론 이러한 플래그를 사용하면 유해한 영향을 줄 수 있으므로 매우 신중해야합니다.