TempDB 경합

SQL Server 2014 SP1에 활성 OLTP 40GB 데이터베이스가 있습니다. IO_Completion 대기, 디스크 큐 길이가 900으로 증가하고 SQL Server가 응답을 중지하면 쿼리 속도가 느려집니다. 우리가 시도한 것 :

1. 인스턴스를 다시 시작하면 1 분 안에 동일한 방식으로 작동합니다.

2. 두 번째 다시 시작한 후 각 tempdb 데이터 파일의 초기 크기 (16 개의 데이터 파일이 생성됨)를 변경하고 올바르게 작동하기 시작합니다.

참고 : 중간 결과 집합에 테이블 변수를 사용하고 있습니다. 이 결과 집합은 매우 작습니다.

한 달에 두 번 일어났습니다. 데이터 파일에 약간의 공간을 수동으로 추가 할 때마다 정상적으로 작동하기 시작합니다. 더 흥미로운 것은 SQL Server 2008 R2와 동일한 설정 (동일한 하드웨어, 동일한 폴더 및 파일 설정, 동일한 작업량) 및 SQL Server 2012가 제대로 작동한다는 것입니다.

영구적 인 해결책을 찾도록 도와주십시오.

모든 데이터 파일의 초기 크기는 1000MB, 현재는 1500MB입니다. 모두 동일합니다. 자동 증가는 각각 100MB입니다. 이 전에 우리는 PFS 및 GAM 페이지 경합에 직면했으며 16으로 증가하고 문제가 해결되었습니다. 두 추적 플래그 1117 및 1118이 모두 사용 가능합니다. 2 개의 NUMA 노드에서 24 개의 코어. 모든 데이터 파일이 같은 볼륨에 있습니다. SAN이없는 간단한 디스크.

인스턴스가 실제 머신에 있습니다. 테이블 변수가있는 쿼리와 해시 조인이있는 쿼리는 IO_Completion 대기를 가장 일반적으로 생성합니다.

wBob의 자세한 답변을 통해 더 자세히 검색 할 수있었습니다. 이전에 어떻게 놓쳤습니까?

데이터베이스 'tempdb'에서 파일 'templog'의 자동 증가가 사용자에 의해 취소되었거나 7704 밀리 초 후에 시간 초과되었습니다. ALTER DATABASE를 사용하여이 파일에 대해 더 작은 FILEGROWTH 값을 설정하거나 새 파일 크기를 명시 적으로 설정하십시오.

이런 유형의 문제가 발생하면 로그에서 발견했습니다. 빠른 드라이브를 분리하기 위해 TempDB를 이동하고 있습니다.

tempdb를 조각 모음했는데 서버 CPU와 디스크 설정이 일치하지 않지만 더 많은 정보를 수집하겠습니다.

질문 / 추가 정보 필요

• 프로세서 이름과 유형을 확인하십시오 (기본적으로 HT가있는 2 x 16 진수 코어인지 확인하려고합니다). 시스템 정보 (예 : 제어판> 시스템 및 보안> Windows Server 2012 R2의 시스템) 및 / 또는 sysinternals 도구 CoreInfo 를 사용하여 확인하십시오.
• 서버 maxdop (예 :)을 확인하십시오 EXEC sp_configure 'max degree of parallelism'. CPU가 16 진 코어 인 경우 서버 maxdop는 최대 6 개 ( 여기에서 와 같이 )이거나 OLTP 시스템에서 더 낮아야합니다. 나는 일반적으로 tempdb 파일을 서버 DOP에 따라 최대 8로 유지하지만 그에 대해 설명하겠습니다.
• 상자의 서버 총 메모리와 SQL Server 메모리 캡 (예 :)을 확인 EXEC sp_configure 'max server memory (MB)'하십시오.
• 박스에서 다른 서비스가 실행 중인지 확인하십시오 (예 : SSIS, SSAS, SSRS, 응용 프로그램, iTunes 등)
• SQL Server 서비스 계정에 대해 인스턴트 파일 초기화가 활성화되어 있는지 확인하십시오. ( 여기 에서 테스트 할 것입니다 ).
• 하나의 디스크 (가정용 PC)와 CPU (2 개의 노드 NUMA 설정 비프) 사이에 이렇게 큰 차이가있는 이유는 무엇입니까? tempdb에 디스크, 스트라이핑, SSD 추가를 고려하십시오 ( 과도하게 반응 하지는 않음 :) .
• 문제 쿼리 중 하나에 대한 실제 실행 계획을 추가하십시오. 원하는 경우 SQL Sentry Plan Explorer 와 익명으로 처리하십시오 .

• OLTP 시스템에서 해시 조인 테이블 변수? 이는 테이블 변수, 기본 테이블 또는 둘 다에서 인덱싱이 부족함을 나타냅니다. 인덱스가없는 이와 같은 테이블 변수를 선언하고 있습니까?

  DECLARE @t TABLE ( x INT )

• 작은 결과 집합을 보유하더라도 테이블 변수 정의를 건너 뛰지 마십시오. 인덱스가 클러스터링 / 클러스터 화되지 않았는지 여부에 관계없이 옵티 마이저에게 가능한 많은 정보를 제공하는 것이 가장 좋습니다.

  DECLARE @t TABLE ( x INT PRIMARY KEY )
  DECLARE @u TABLE ( x INT PRIMARY KEY NONCLUSTERED, u INT NOT NULL UNIQUE CLUSTERED, z INT NOT NULL UNIQUE, a CHAR(1) NULL ) -- not sure why you would do this but you can
  DECLARE @v TABLE ( x INT NOT NULL, y INT NOT NULL, PRIMARY KEY ( x, y ) )   -- multi-column primary key

• 실행 계획을 게시하면이를 진단하는 데 도움이됩니다.

• 여기 에 따라 테이블 변수 캐싱을 방지하는 코드를 확인 하십시오 . WITH RECOMPILE로 실행 된 동적 SQL 및 proc만이 테이블 변수에 영향을 미치는 것 같습니다.

  DECLARE @u TABLE ( x INT )
  
  INSERT @u
  EXEC('DECLARE @t TABLE ( x INT ); INSERT INTO @t VALUES ( 1 ); SELECT x FROM @t;' )
  
  SELECT *
  FROM @u

• IO 경고와 같은 메시지에 대해서는 SQL Server 로그 (개체 탐색기> 관리> SQL Server 로그)를 확인하십시오.

• Windows 이벤트 뷰어 확인
• SP1 이후 많은 빌드가 릴리스되었습니다. SP1 이후에 삽입 된 CU 수정 사항을 검토하십시오 . SP1에 다음 CU에서 수정 된 버그가있을 수 있습니다. 예 : FIX : 예상 행 수 및 행 크기가 올바른 경우 SQL Server 2012 또는 SQL Server 2014에서 정렬 연산자 유출이 tempdb로 https://support.microsoft.com/en- us / kb / 3088480
• 새로운 기능 (메모리 내 OLTP, 클러스터 된 columnstore)의 수로 인해 SQL Server 2014와 함께 CU를 최신 상태로 유지하는 것이 더 중요하지만 핫픽스를 적용하기 전에이 원인을 설정하십시오.
• 마지막으로 코어 당 하나의 tempdb 파일이 필요하다는 것은 신화 이며 디스크 설정을 보면 tempdb가 지나치게 조각화되어 있다고 생각합니다. 하나의 디스크 헤드가 있고, tempdb에는 하나의 파일 그룹이 있고 많은 파일이 있습니다.

그러나 우리가 알고 있다고 생각하는 것을 잊어 버리십시오. 문제를 재현하는 테스트 장비를 만들고 임시 파일 수를 줄이십시오. 1, 2, 4, 6에서 시작하여 정보를 수집하여 증거 기반 결정을 내립니다. 이제는 문제가 간헐적으로 보이고 tempdb 설정을 망칠 수 없기 때문에 이것이 더 어렵습니다. 그러나 이것이 내가 접근하는 방법입니다.

행운을 빕니다. 어떻게하는지 알려주십시오.