SQL Server에서 DB가 축소되는 경우가 많으므로 걱정할만한 충분한 이유가 있습니다. SQL 2005의 스토리지 엔진 책임자 인 Paul Randal은 ShrinkDB가 매우 잘못 작성되었습니다. 맨 처음에 데이터를 가져 와서 빈 공간을 찾아 맨 처음에 넣고 DB 파일의 '끝'에 여유 공간이 생길 때까지 계속하십시오. 이 시점에서 SQL Server에서 공간을 해제하여 OS에 다시 제공 할 수 있습니다. 데이터베이스 파일을 효과적으로 되돌 리므로 일반적으로 대규모 조각화가 나타납니다. 이 블로그 게시물 또는이 MCM 내부 동영상 에서 자신의 의견을 읽을 수 있습니다.
모든 것과 마찬가지로 실제로 환경에서 먼저 테스트해야합니다. 더 좋은 방법은 데이터를 다른 파일 그룹으로 옮기는 것입니다. 클러스터형 인덱스를 사용하여 온라인 인덱스를 다시 작성한 다음 새 파일 그룹에서 다시 인덱스를 작성할 수 있습니다. 그런 다음 이전 것을 삭제하고 공간을 해제하고 조각화가 거의 없습니다. 이 작업을 수행하는 동안 약 120 %의 추가 공간이 필요합니다. 이것의 문제점은 당신이 가지고 있지 않은 것처럼 보이는 추가 여유 공간이 필요하다는 것입니다. 이것은 엔터프라이즈 기능입니다.
여유 공간이 부족한 경우 프로세스를 오래 실행하지 않으려면 총알을 물고 한 번에 작은 덩어리로 천천히 DB를 축소해야 할 수도 있습니다. 데이터가 많이 조각화되어 모든 것을 다시 색인화하려고합니다. 모든 것을 재색 인한 후에는 사용 된 공간을 약간 늘리고 추가 여유 공간으로 돌아갑니다. 여기에서 Brent의 조언을 참조 하십시오 .
사용 가능한 공간이 얼마나 좋은지에 대해서는 조각화 및 파일 증가 활동을 얼마나 감당할 수 있는지가 중요합니다. IFI를 사용하면 파일 크기가 거의 즉시 증가하지만 여전히 조각화가 발생합니다. 경험상 필요한 규칙은 필요한만큼의 공간을 미리 할당하거나 필요한 경우 성장을 모니터링하고 청크를 주기적으로 조정하는 것입니다. 이것은 물리적 조각화를 유지합니다.
또한 로그 파일 증가가 훨씬 중요합니다. 추가 로그 파일로 인해 VLF 조각화가 발생할 수 있습니다. 이로 인해 복원 속도가 훨씬 느려지고 검사 점 / 절단에 영향을 줄 수 있습니다. 조각난 로그로 인한 성능 위험은 다음과 같습니다 . 를 수행 DBCC LOGINFO();각 데이터베이스에. Kim Tripp 당 약 50ish를 유지하십시오. 그러나 수백 개가 보이면 조각화 문제가있어 작업을 지원하기 위해 로그 파일이 커져야했습니다. Paul Randal에 따라 로그 파일이 무엇인지 확인하는 좋은 방법은 일주일 동안 자라서 색인을 다시 생성하는 것입니다. 그것은 좋은 지적 일 수 있습니다. 아마도 경우에 대비하여 약간 더 많은 여유 공간을 확보 할 수 있습니다. DBCC LOGINFO ()로 로그가 조각화되지 않았는지 확인하십시오. 다시 그리고 그들이 있다면, 그들은 많이 자랐 음을 의미합니다. 다음을 사용하여 로그 파일 축소 및 재 확장이 방법 .