인덱스를 다시 작성할 때 sort_in_tempdb를 사용하는시기


22

DW 테이블에 SORT_IN_TEMPDB 옵션을 사용할지 여부에 대해 논의 중입니다. 나는이 옵션을 사용할 때 더 순차적이지만 더 많은 쓰기가 있다는 것을 이해합니다. SAN (때때로 악명을 느 꼈음)이 있으므로 가능한 한 쓰기 수를 제한하려고합니다. tempdb는 별도의 LUN (디스크 세트)에 있다고 생각합니다.

데이터 파일과 tempdb 파일에 충분한 디스크 공간이 있습니다. 이 경우 SORT_IN_TEMPDB를 사용하면 이점이 있습니까?

저를 강타한 한 가지는이 답변 에 대한이 의견이었습니다

인덱스를 다시 작성할 때는 인덱스 공간의 두 배 + 정렬을 위해 20 %가 필요합니다. 따라서 일반적으로 DB의 모든 인덱스를 다시 작성하려면 DB에서 가장 큰 인덱스의 120 % 만 필요합니다. SORT_IN_TEMPDB를 사용하는 경우 20 % 만이기더라도 여전히 데이터 파일에 추가 100 %가 필요합니다. 또한 tempdb에서 sort를 사용하면 인덱스를 데이터 파일에 한 번 쓰는 대신 이제 tempdb에 한 번 쓴 다음 데이터 파일에 쓸 수 있으므로 IO로드가 크게 증가합니다. 따라서 항상 이상적인 것은 아닙니다.

우리는 느리거나 잘못 구성된 SAN으로 IO 부하를 늘리고 싶지 않습니다.

이것을 테스트하는 가장 좋은 방법은 무엇입니까? 옵션을 사용하거나 사용하지 않고 단순히 테이블을 다시 작성하고 시간을 기록하면?

편집 : 각 15GB의 8 개의 tempdb 파일이 있습니다. TF 1117/1118 플래그가 설정되었으며 IFI가 활성화되었습니다. 우리는 현재 sort_in_tempdb 옵션을 사용하거나 사용하지 않고 재구성을 혼합하여 수행합니다.

감사!

SQL Server 2012 엔터프라이즈

답변:


22

SORT_IN_TEMPDBtempdb, 인덱스를 다시 작성하는 사용자 데이터베이스에 공간을 할당하는 대신 SQL Server가 임시 공간을 할당하는 데 사용합니다. 이는 인덱스 재 구축 작업 동안 사용자 데이터베이스에 여유 공간이 덜 필요하고 tempdb에 여유 공간이 더 필요하다는 것을 의미합니다.

tempdb가 사용자 데이터베이스와 다른 디스크 세트 (LUN)에있을 때 더 유리합니다.

SORT_IN_TEMPDB 옵션 에서 -BOL :

경우 SORT_IN_TEMPDB 옵션을 ON으로 설정하고 tempdb를이 디스크의 별도의 세트입니다 대상 파일 그룹에서 첫 번째 단계는이 페이지의 tempdb에서 정렬 작업 영역에 쓰기에서 다른 디스크에 발생하는 데이터를 읽습니다. 즉, 데이터 키의 디스크 읽기는 일반적으로 디스크 전체에서 더 연속적으로 진행되며 tempdb 디스크에 대한 쓰기도 일반적으로 연속적이며 최종 인덱스를 작성하기위한 쓰기도 마찬가지입니다. 다른 사용자가 데이터베이스를 사용하고 별도의 디스크 주소에 액세스하더라도 SORT_IN_TEMPDB가 지정 되지 않은 경우 보다 지정되면 전반적인 읽기 및 쓰기 패턴이 더 효율적 입니다.

SORT_IN_TEMPDB가 ON 인 경우 디스크 공간 요구 사항 을 읽으십시오 .

느리거나 잘못 구성된 SAN

당신은 고통의 포인트를 알고 있습니다. SAN 관리자와 함께 문제를 해결하지 않는 이유는 무엇입니까? SAN이 잘못 구성되거나 느리면 속도 저하와 같은 모든 종류의 문제 가 발생합니다 .

몇 가지 중요 사항 :

이것을 테스트하는 가장 좋은 방법은 무엇입니까?

예,를 사용하거나 사용하지 않고 인덱스를 재 구축 할 때 waitstats분석하여 테스트해야합니다 SORT_IN_TEMPDB. 실행 시간과 PROD를 수행 할 때 유지 관리 기간 동안 또는 서버 작업이 적은 시간에 실행 시간을 측정하십시오. 또한 읽기 / 쓰기 데이터 및 로그 대기 시간을 확인하십시오 .

나는 당신이 인스턴트 파일 초기화를 확신하지 못하지만 데이터 파일의 자동 증가시 및 새로운 데이터베이스를 생성 할 때 (완전성을 언급하면서) 복원 할 때 도움이됩니다.


tempdb 구성으로 의견을 편집했습니다. 감사합니다, 시리얼 온라인 재 구축 팁에 대해 몰랐습니다. 좀 더 많은 테스트를 수행하고 불행히도 환영받지 못한 SAN 관리자에게 문의하려고합니다. 비교해야 할 특정 대기 통계가 있습니까 (예 : PageIOLatch)? 우리의 tempdb 쓰기는 끔찍한 최고 (4000ms)입니다. 주요 DB의 경우 40ms 미만 그래도 다른 질문이 될 수 있습니다 ...!
Gabe

읽기 / 쓰기 대기 시간 - - 당신이 참으로 SAN 문제입니다 귀하의 SAN 관리 적절한 사실을 표시해야합니다 @Gabe 되는 sys.dm_io_virtual_file_stats . tempdb가 별도의 LUN에 있습니까?
Kin Shah
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.