TempDB에서의 DDL 경합

지난 몇 달 동안 TempDB DDL 경합에 문제가있는 SQL Server 2005 Standard x64가 있습니다. 서버는 대기 자원 2 : 1 : 103 (대기 유형이 PAGELATCH_EX 임)에 경합이 발생합니다.

서버의로드가 적절하지 않으면이 문제가 산발적으로 발생하는 것으로 보입니다. "파괴를위한 임시 테이블"비율을 모니터링하고 있으며 2 : 1 : 103에 PAGELATCH_EX 문제가있는 시간 동안 5,000 이상으로 이동할 수 있습니다. 내가 읽은 것으로 부터이 카운터는 대부분 0이어야하지만, 우리는 대부분 300-1100에서 머무르는 것으로 보입니다. 시스템에 사용자가 매우 적은 경우에만 카운터가 0으로 이동합니다.

건초 더미에서 바늘을 찾지 않고도 tempdb에서 DDL 경합을 일으키는 원인을 어떻게 좁힐 수 있습니까?

나는이 문제를 보았고 궁극적으로 수정하기 위해 발표 된 핫픽스는 실제로 Microsoft CSS의 경우의 직접적인 결과였습니다. 수정에 대한 공개 KB 기사가 없습니다. 서비스 팩 4 와 최신 누적 업데이트를 SQL Server에 적용했는지 확인하십시오 (작성 당시 누적 업데이트 # 3 (9.00.5259) ).

핫픽스가 출시 될 때까지 Microsoft의 제안은 #temp 테이블 만들기 ( KB # 916086 과 유사)를 중단하는 것 입니다. 이것이 수십 및 수십 개의보고 절차를 상당 부분 다시 작성했음을 의미하기 때문에 필자의 경우 해결 방법 (추적 플래그 또는 임시 파일 레이아웃에 관계없이)은 주말마다 클러스터를 다시 시작해야했습니다. 왝.

tempdb 사용을 추적하기 위해 Adam Machanic의 sp_whoIsActive를 참조하여 도움이되는 몇 가지 스크립트가 있습니다 .

• sp_whoisactive : Tempdb 경합 분석
• tempdb 트랜잭션 로그를 채우는 쿼리를 식별하는 방법은 무엇입니까?

또한 @SQLSoldier 의이 스크립트 (및 주석의 스크립트) :

• TempDB 경합 분석

모든 커서가 사용하고 있는지 확인하고 LOCAL STATIC READ_ONLY FORWARD_ONLY( this 및 this 참조 ) #temp 테이블 / @table 변수, CTE를 광범위하게 사용하거나 불필요한 정렬을 포함하거나 해시 조인으로 이어질 수있는 알려진 값 비싼 쿼리가 있는지 확인하십시오. ...이 모든 것이 문제에 기여할 수 있습니다. "buck-for-your-buck"시작점으로 가장 쉬운 스위핑 수정은 기본값 대신 적절하고 저렴한 커서 옵션을 사용하는 것입니다.

그 동안 (a) CU # 3을 설치하고 (b) PSS를 호출합니다. "VSTS # 109112-임시 테이블 지연된 드롭이 특정 워크로드에 대해 확장되지 않는다" 는 이미 버그로 확인되어 다른 사용자에게 개인용 핫픽스로 릴리스 된 매우 특정한 수정이 이루어 졌음을 알려줍니다. 처음에 사례 비용을 지불해야 할 수도 있지만 버그이기 때문에 비용을 환불해야합니다.

추적 플래그 1118이 필요할 수 있습니다.

참조 tempdb에 대한 바울 랜달의 신화 첫째, 자신 도 TF 1118 기사

TF는 여기 KB 328551에 설명되어 있습니다.

나는 이것에 대한 직접적인 경험이 없지만 내가 읽은 것처럼 들린다.

나는 이미 TempDB 데이터 파일을 분할하여 경합을 완화하려고 시도합니다 (사전 프로덕션을 통해 분명히). 용감한 사람이라면 Paul Randal이 공식적으로 다음을 참조 하는 추적 플래그를 고려하십시오. -tempdb-should-always-have-one-data-file-per-processor-core.aspx

고통을 일으키는 원인과 관련하여 조사 작업을 수행해야합니다.

• 이것이 방금 시작 되었습니까? 무엇이 바뀌 었습니까?
• 서버의 메모리가 부족하므로 TempDB에서 정렬을 수행해야합니까?
• CheckDB와 같은 DBA 프로세스 또는 온라인 재색 인화가 실행 중입니까?
• 보다 이국적인 격리 수준 또는 서비스 브로커가 사용됩니까? sys.databases를 살펴보십시오

이 Microsoft TempDB 문서의 맨 아래에는 tempdb를 사용하는 작업을 시도하기위한 멋진 쿼리가 있습니다. http://technet.microsoft.com/en-gb/library/cc966545.aspx

여전히이 문제를 추적하려는 경우 동기 테이블 삭제와 비슷한 성능 문제가 최근에 발생했습니다. SQL 2005를 실행하는 SQL 인스턴스에 많은 수의 데이터베이스 (> 100 정도)가 있고 임시 테이블 작성 및 삭제 명령문이 많은 경우 임시 테이블 삭제가 느려질 수 있습니다. sys.dm_db_index_usage_stats에서 반환 된 행 수를 확인하면이 문제를 범인으로 거의 즉시 배제 할 수 있습니다.

KB 기사는 문제를 설명합니다. http://support.microsoft.com/kb/2003031

sys.dm_db_index_usage_stats에 많은 행이 있으면 쿼리 성능이 저하됩니다.

다음 시나리오를 고려하십시오.

Microsoft SQL Server 2005에서는 많은 테이블 (특히 tempdb 데이터베이스의 임시 테이블)의 삭제 및 재생과 관련된 DDL 작업을 자주 수행합니다. sys.dm_db_index_usage_stats DMV (Dynamic Management View)에 많은 항목 (100,000 개 이상)이 있습니다.

이 질문에 대한 나의 대답에서 가져 왔습니다. 더 자세한 내용도 있습니다. SQL 2005에서 느린 임시 테이블 삭제