이상한 행동 DBCC 축소 ​​파일

95 %의 데이터가 보관되고 삭제 된 데이터베이스에 대해 1GB 청크로 dbcc shrinkfile을 실행하려고합니다. 9GB가 데이터 / 인덱스 인 235GB 파일이 있습니다. 이 크기를 50GB로 줄이려고합니다. 데이터베이스 파일 축소가 나쁘고 조각화 등이 발생한다는 것을 알고 있습니다. 데이터 제거 / 수축의 일부로 idnex 스크립트 다시 작성도 있습니다.

내 워크 스테이션 (쿼드 코어, 12GB RAM, 2 x SATA 드라이브)의 데이터베이스에 대해 dbcc shrinkfile 스크립트를 실행하면 약 8-10 분이 걸립니다.

테스트 환경 (80 개 이상의 코어, 128GB RAM, SSD SAN)에서 동일한 데이터베이스 포스트 데이터 제거 사본에 대해 동일한 코드를 실행할 때 70 분이 소요됩니다. 참고로, 축소 파일이 실행될 때이 서버에서 활동이 거의 없습니다. 동일한 결과로 4 회 실행되었습니다.

그런 다음 나머지 9GB를 다른 파일 그룹 및 실제 파일로 이동하는 다른 접근 방식을 취했습니다. 빈 230GB 파일에서 dbcc shrinkfile을 실행하여 50GB로 줄이면 내 워크 스테이션에서 1 분 미만이 걸립니다.

이와 동일한 접근 방식을 사용하면 테스트 환경에서 70 분 이상이 다시 걸립니다.

테스트 환경에서 70 분 동안 Brent Ozar의 스크립트에 따라 전후 스 탯의 스냅 샷을 찍었고 waittypes는 아무런 문제가 없음을 보여주었습니다. 아래 3 개 행 :

두 번째 샘플 시간 샘플 지속 시간 (초) wait_type 대기 시간 (초) 대기 횟수 평균 대기 당 ms
2013-05-28 11 : 24 : 22.893 3600 WRITELOG 160.8 143066 1.1
2013-05-28 11 : 24 : 22.893 3600 CXPACKET 20.9 13915 1.5
2013-05-28 11 : 24 : 22.893 3600 PAGELATCH_EX 11.1 443038 0.0

Windows 이벤트 로그에는 이상한 것이 없습니다. 나는이 시점에서 긁힘을 겪고 있는데, 왜 독립형 워크 스테이션에 비해 닌자 하드웨어에서 오래 걸리는 이유입니다.

데이터 파일의 축소 파일은 작은 메모리 버퍼를 재사용하는 단일 스레드 작업입니다.

따라서 Ninja 하드웨어는 추가 메모리와 80 코어로 우위를 점하지 못했습니다.

그러나 로컬 PC는 로컬 I / O 대기 시간 (로컬 디스크, 즉 SAN으로 여러 번 이동할 필요가 없음)이라는 이점이 있습니다.