SQL Server 2014에서 전체 검색이 포함 된 업데이트 통계는 100 % CPU, 2008 R2, 15 %


10

동일한 테이블에 대해 하드웨어 기능이 비슷한 SQL Server 2008 R2에서 CPU의 20 %를 사용하는 경우 SQL Server 2014에서 전체 검색 업데이트 통계가 CPU의 100 %를 사용하는 이유는 무엇입니까?

나는 MAXDOP다른 옵션을 보고 있었고 실제로 눈에 띄는 것은 없습니다. 이 문제를 일으킬 수있는 설정이있을 수 있지만 두 데이터베이스의 설정은 매우 유사합니다 (예 : MAXDOP둘 다 코어가있는 두 데이터베이스 모두 4). 둘 다 Enterprise Edition입니다.

SQL Server 2014와 SQL Server 2008 R2에이를 설명 할 수있는 "다른"것이 있습니까? 두 서버 모두 메모리 옵션이 90 %입니다. 무엇을 찾아야할지 생각이 있습니까?

SQL Server 2008 R2 / SP3 및 SQL Server 2014 / SP2를 사용하여 두 서버에서 일주일에 한 번 전체 (100 %) 스캔으로 업데이트 통계를 실행하며 데이터베이스의 구조는 동일합니다. 2008 R2 서버에서 매우 큰 두 테이블의 업데이트 통계는 몇 시간이 걸리지 만 예상 한 시간이지만 CPU는 전체 시간의 20 % 이하로 유지됩니다. 그러나 2014 서버에서는 CPU가 약 40 분 동안 100 %로 이동합니다. 2014 서버에서는 테이블이 약간 작습니다. SQL Monitor 분석 메뉴를 사용하여 이것을 봅니다.

다음은 2014 SQL Server의 Ola 로그 파일 출력입니다. CPU는 약 2:10에서 2:45로 100 %가됩니다.

Date and time: 2017-06-24 02:10:20  
Command: UPDATE STATISTICS [InVA].[dbo].[AuditField] [_WA_Sys_00000005_15502E78] WITH FULLSCAN  
Outcome: Succeeded  
Duration: 00:07:48  
Date and time: 2017-06-24 02:18:08  
Date and time: 2017-06-24 02:18:08  
Command: UPDATE STATISTICS [InVA].[dbo].[AuditField] [_WA_Sys_00000006_15502E78] WITH FULLSCAN  
Outcome: Succeeded  
Duration: 00:32:22  
Date and time: 2017-06-24 02:50:30  

위의 두 가지 통계에 대한 2008 R2 SQL Server의 Ola 로그 파일 출력은 다음과 같지만 CPU는 15 %가됩니다.

Date and time: 2017-06-24 03:30:32  
Command: UPDATE STATISTICS [InGA].[dbo].[AuditField] [_WA_Sys_00000003_0425A276] WITH FULLSCAN  
Outcome: Succeeded  
Duration: 00:05:00  
Date and time: 2017-06-24 03:35:32  
Date and time: 2017-06-24 03:35:32  
Command: UPDATE STATISTICS [InGA].[dbo].[AuditField] [_WA_Sys_00000004_0425A276] WITH FULLSCAN  
Outcome: Succeeded  
Duration: 00:52:31  
Date and time: 2017-06-24 04:28:03

모든 병렬 계획 생성이 제거되어 응용 프로그램을 손상시킬 수 있으므로 서버 maxdop = 1로 실행할 수 없습니다. 나는 반대 방향으로 가서 8로 늘릴 계획입니다 (상자에 16 개의 코어가 있음). CPU가 페깅되는 시간을 줄이기 위해 더 빨라질 수 있습니다. 이 작업은 사용자가 거의없는 동안 실행됩니다.


프로세스가 2008 R2 서버에서 IO 바인딩되어 있는지 확인 했습니까? 는 IS tempdb구성은 동일? UPDATE STATISTICS실행 하는 동안 사용할 수 있으므로 문제가 될 수도 있습니다.
MicSim

1
나도 평행이 아마도 범인 일 것이라고 생각할 것이다. 병렬 처리에 대한 비용 임계 값을 우연히 확인 했습니까? 또한 두 상자에서 전체 sp_configure 목록을 가져 와서 다른 것을 확인하기 위해 diff하는 것이 좋습니다.
DBADon

답변:


1

SQL Server의 다양한 옵션을 기반으로 통계 업데이트가 병렬로 진행될 수 있습니다.

  • 병렬 처리에 대한 비용 임계 값 -병렬 처리 기차를 타려면 쿼리가이 값보다 높아야합니다. 두 서버에는 서로 다른 CTFP 설정이있어 2008R2 업데이트가 단일 스레드로 전환되는 반면 2014 서버는 다중 스레드로 전환 될 수 있습니다.
  • 최대 병렬 처리 수준-SQL Server가 병렬 처리하기로 결정한 경우 쿼리에서 사용할 수있는 코어 수를 결정합니다. 2008R2 상자에는 MAXDOP가 1로 설정되어 있고 2014 상자에는 기본값 0 (무제한)이 설정되어있을 수 있습니다.
  • 리소스 관리자 -이 Enterprise Edition 기능을 사용하면 다양한 사용자 또는 응용 프로그램 그룹을 다른 MAXDOP로 제한 할 수 있습니다.

이후 버전의 SQL Server (2016 이상)에서는 훨씬 더 복잡해집니다.

  • 데이터베이스 레벨 범위 옵션 - 데이터베이스 를 마우스 오른쪽 단추로 클릭하고 특성으로 이동하여 해당 데이터베이스의 MAXDOP 레벨을 설정할 수 있습니다.
  • 통계 병렬 힌트 -2016 SP2부터 통계 생성 및 업데이트 문은 MAXDOP 힌트를 허용합니다.

언급했듯이 2008R2 하나는 단일 스레드로 진행되는 반면 2014 하나는 다중 스레드로 진행됩니다 (따라서 더 빨리 마무리하지만 실행되는 동안 CPU를 최대로 사용).

통계 작업에 적합한 균형을 찾으려면 다음을 고려하십시오.

  • 데이터베이스에서 다른 작업이 동시에 일어나고 있습니까? 짧은 기간 동안 상자를 지배 할 여유가 있습니까? 예를 들어, 대부분의 주말 시간 동안 유휴 상태 인 데이터웨어 하우스에서 서버를 사용하지 않는 사람이 아무도 없다는 사실을 알면 전체 스캔으로 통계 업데이트에 어려움을 겪는 사람들이 있습니다. 트랜잭션이 많은 환경에서는 자정에도 사용자가 불만을 제기 할 경우 유지 관리 작업에 미치는 영향을 최소화해야합니다.
  • 전체 스캔이 정말로 필요합니까? fullscan 옵션을 사용할 때 좋은 계획 만 가져 오는 쿼리가 표시됩니까? 아니면 최선의 방법으로 수행하고 있습니까? 데이터베이스가 커짐에 따라 하드웨어 투자에 보조를 맞추지 않으면 전체 스캔을 수행하는 대신 통계 샘플링에서 트레이드 오프를 시작해야 할 수도 있습니다.
  • 통계를 덜 자주 업데이트 할 수 있습니까? 예를 들어, 주말마다 통계의 1/4를 업데이트 한 다음 매달 통계 업데이트를받을 수 있습니까?
  • 더 적은 객체를 업데이트 할 수 있습니까? 수십 개의 새로운 삽입이 수행 되었기 때문에 거대한 감사 또는 아카이브 테이블에서도 통계를 업데이트하는 사람들이 종종 있지만 이러한 삽입은 실제로 테이블의 통계에 영향을 미치지 않습니다 (아무도 아무도 쿼리하지 않습니다).

0

커뮤니티 위키 답변 :

최선의 추측 : 통계 업데이트를 위해 선택한 계획은 2008 R2 상자보다 2014 상자에서 평행 또는 더 평행합니다.

병렬 업데이트 통계 fullscan는 2005 년부터 사용되었으며 2016 년부터 샘플링 된 통계 는 SQL Server 데이터베이스 엔진 블로그에서 Gjorgji Gjeorgjievski의 SQL Server 2016의 쿼리 최적화 프로그램 추가 사항을 참조하십시오 .

Enterprise Edition이있는 경우 리소스 관리자 를 사용하여 유지 관리 작업에서 사용중인 CPU를 제한 할 수 있습니다 .

Javier Villegas의 통계 업데이트 에 대한 Connect 제안 제안 추가 MAXDOP매개 변수에 대한 투표도 고려하십시오 .

관련 Q & A : 병렬 통계 ​​업데이트

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.