예상 실행 계획을 표시하면 CXPACKET, PAGELATCH_SH 및 LATCH_EX가 생성됩니다. [ACCESS_METHODS_DATASET_PARENT] 대기

내가 가진 4의 vCPU VM에서 Microsoft SQL 서버 2016 SP2 - CU6 (13.0.5292.0)를 실행 해요 max degree of parallelism로 설정 2하고 cost threshold for parallelism로 설정 50.

아침에 SELECT TOP 100 쿼리에 대한 예상 실행 계획 을 표시하려고 할 때 대기 시간이 길어지고 예상 계획을 렌더링하는 데 5 분-7 분 범위의 시간이 소요됩니다. 다시 한 번, 이것은 실제 쿼리 실행이 아니라 예상 실행 계획 을 표시하는 프로세스 일뿐 입니다.

sp_WhoIsActivePAGEIOLATCH_SH대기 또는 LATCH_EX [ACCESS_METHODS_DATASET_PARENT]대기 를 표시 하고 작업 중에 Paul Randal의 WaitingTasks.sql 스크립트를 실행하면 대기자를CXPACKET 표시하는 작업자 스레드와 함께 대기를 표시합니다 PAGEIOLATCH_SH.

* 자원 설명 필드 = exchangeEvent id=Port5f6069e600 WaitType=e_waitPortOpen waiterType=Coordinator nodeId=1 tid=0 ownerActivity=notYetOpened waiterActivity=waitForAllOwnersToOpen

작업자 스레드는 전체 stats테이블을 메모리로 가져 오는 것으로 보입니다 (Paul Randal의 쿼리 지점에서 표시되는 후속 페이지 번호 및 해당 페이지 번호는 stats테이블의 클러스터 된 키로 다시 표시됨). 일단 계획이 돌아 오면, 기본적으로 stats여러 레코드 만 남은 캐시에서 대부분의 테이블 삭제 를 본 후에도 기본적으로 즉각적인 순간입니다 (유사한 쿼리에서 작업을 찾기 위해 풀려 났다고 가정).

쿼리가 실제로 SCAN 연산자를 사용하는 계획으로 실행 된 경우이 초기 동작이 예상되지만 위의 계획에 표시된 것처럼 SEEK 연산자에만 도달하도록 실행 계획을 평가할 때 왜 그렇게합니까? 여기서 성능 향상을 위해 근무 시간 전에이 명령문을 실행하는 것 외에 데이터를 적절히 캐시 할 수있는 방법은 무엇입니까? 커버링 인덱스 쌍이 도움이 될 것이라고 가정하지만 실제로 동작의 변경을 보장합니까? 여기에서는 일부 스토리지 및 유지 관리 기간 제한 내에서 작업해야하며 쿼리 자체는 공급 업체 솔루션에서 생성 되므로이 시점에서 다른 제안 (더 나은 인덱싱 제외)을 환영합니다.

실제 실행 계획에 따른 통계 업데이트 요청이 표시됩니다. 아침에 이런 일이 발생한다고 언급 했으므로 관련된 테이블을 많이 수정하는 야간 프로세스가 있다고 생각합니까?

따라서 SQL Server는 통계를 사용하여 계획을 만들고 수정 임계 값에 도달했으며 작업의 일부로 자동 통계 업데이트를 실행합니다.

귀하가 공유 한 예상 요금제에 대한 XML에서 오늘 아침부터 통계에 대한 업데이트 날짜가 다음과 같이 표시됩니다.

LastUpdate="2019-05-06T09:12:49.92"
LastUpdate="2019-05-06T09:12:58.3"
LastUpdate="2019-05-06T09:13:20.33"
LastUpdate="2019-05-06T09:13:09.67"
LastUpdate="2019-05-06T09:12:59.05"
LastUpdate="2019-05-06T09:12:39.56"

이 테이블이 매우 크고 사용량이 많은 테이블 인 경우 (샘플링 백분율을 기준으로 한 것으로 보임) 통계 업데이트가 많은 마력을 취하고 있다는 것은 그리 놀라운 일이 아닙니다 .

SSMS에서 계획된 계획 시간이 길면 가능성이 높은 순서대로 다음 중 하나입니다.

1. 쿼리 최적화 프로그램은 통계를 작성하거나 업데이트해야한다고 결정했습니다.
2. 예상 계획의 크기가 매우 커서 (예 :> 10MB) SSMS를 표시하는 데 시간이 오래 걸립니다.
3. 쿼리 컴파일 자체는 실제로 충분한 계획을 찾는 데 CPU 사용량으로 인해 오랜 시간이 걸렸습니다.
4. 서버가 극심한 압박을 받고 있습니다. 예를 들어 게이트웨이 를 사용할 수있을 때까지 기다려야 할 수 있습니다.
5. 컴파일 시간을 크게 연장시키는 다양한 버그.

귀하의 상황에 대한 대답은 SQL Server가 통계를 업데이트하거나 생성하고 있다는 것입니다. 몇 가지 단서가 있습니다. 쿼리 계획의 크기가 작고, 쿼리 계획이 비교적 간단하고 저렴한 비용으로 컴파일 CPU가 컴파일 시간보다 상당히 낮습니다.

새로운 기고자 Josh Darnell 은 또한 XML 통계의 마지막 업데이트 시간에 대한 좋은 실마리를 지적했습니다.

SQL Server 2019에는 쿼리가 통계 업데이트를 기다리는 경우를위한 새로운 대기 유형 인 WAIT_ON_SYNC_STATISTICS_REFRESH가 도입되었습니다 . 해당 버전에서이 문제를 진단하는 것이 훨씬 쉽습니다. 그때까지는 간접 기술에만 의존해야합니다.

해결 방법에는 유지 관리 기간 동안 통계를 업데이트하거나 데이터베이스에 대해 자동 업데이트 통계 비동기를 활성화하는 것이 포함됩니다. 변경하기 전에 해당 옵션의 전체 결과를 이해하십시오. 통계가 업데이트 된 후 대신 통계가 업데이트되기 전에 쿼리 계획이 작성됩니다. 큰 작업 일 수있는 일부 워크로드의 경우. 다른 사람들에게는 선보다 해를 더 많이 줄 수 있습니다.