디스크 공간을 확보하기 위해 MS SQL Server 가져 오기


9

잘못 관리되는 데이터베이스 테이블은 엄청나게 커졌습니다. 48 개 이상의 고아 기록. 정리하고 위험한 하드 드라이브를 정상 상태로 되돌리려 고합니다. 이 테이블에서 약 4 억 개의 레코드를 삭제합니다. 내가 입력하면서 실행 중입니다. 하드 드라이브 공간이 줄어들지 않지만 시스템 테이블 쿼리에서 메모리가 떨어지는 것을 보았습니다. 테이블 크기를 얻기 위해 실행 중입니다. 데이터베이스가 "간단한 복구 모델"을 사용하고 있습니다.

데이터베이스를 축소해야한다는 응답이있는 이와 유사한 질문이 많이 있습니다. 그러나 그들은 조각난 데이터 등으로 인해 이것이 얼마나 나쁜 / 무서운지 설명합니다.

  1. 데이터베이스는이 크기가 아니어야합니다. 축소하는 것이 여전히 나쁩니 까?
  2. 이것은 프로덕션 데이터베이스입니다. 축소하면 가동 중지 시간이 발생하거나 데이터베이스가 잠길 수 있습니까?
  3. SQL Server Management Studio에는 축소, 데이터베이스 또는 파일에 대한 두 가지 옵션이 있습니다. 내 상황에서 가장 좋은 옵션은 무엇입니까?
  4. DB에 필요한 여유 공간의 백분율에 대한 규칙이 있습니까?

축소에 대한 태그 설명을 읽더라도 그렇게하고 싶지 않습니다. 다른 방법이 있습니까?

답변:


14

이 테이블에서 약 4 억 개의 레코드를 삭제합니다.

바라건대, 트랜잭션 로그가 부풀어 오르는 것을 피하기 위해 덩어리로하고 있기를 바랍니다 .

하드 드라이브 공간이 줄어들지 않습니다.

공간을 해제하기 위해 데이터베이스 파일을 명시 적으로 축소해야하기 때문에 그렇지 않습니다. 레코드를 삭제하기 만하면 SQL Server는 공간을 다시 OS로 해제하지 않습니다 .

  1. 데이터베이스는이 크기가 아니어야합니다. 축소하는 것이 여전히 나쁩니 까?

데이터베이스의 크기를 올바르게 조정해야하므로 일반적으로 나쁜 습관입니다. 데이터베이스 가이 크기 가 되지 않을 것이라고 100 % 확신하는 경우 데이터베이스를 축소 해도 됩니다 (시나리오에서) .

  1. 이것은 프로덕션 데이터베이스입니다. 축소하면 가동 중지 시간이 발생하거나 데이터베이스가 잠길 수 있습니까?

데이터베이스 축소는 매우 IO 집약적입니다. DBCC SHRINKFILE유지 관리 기간 동안 또는 활동이 최소 일 때 축소하는 것이 좋습니다 .

  1. 관리 스튜디오에는 데이터베이스 또는 파일의 두 가지 옵션이 있습니다. 내 상황에서 가장 좋은 옵션은 무엇입니까?

축소를 수행하려면 TSQL을 사용해야합니다. (당신이 물었으므로 FILE 축소 는 데이터베이스 대신 갈 길이입니다). 청크 축소 데이터베이스를 사용 하여 청크 축소-tsql 스크립트를 사용하여 청크 축소를 수행 할 수 있습니다 .

축소하면 인덱스가 조각화된다는 것을 기억하십시오.

  1. DB에 필요한 여유 공간의 백분율에 대한 규칙이 있습니까?

데이터베이스에 필요한 디스크 공간 요구 사항 기사 참조 할 수 있습니다 . 수정 규칙이 없으므로 데이터베이스가 어떻게 커질 지 고려해야합니다. 또한 데이터베이스의 자동 증가 를 고려해야 합니다 .

참조 : 트랜잭션 로그가 계속 늘어나거나 공간이 부족한 이유는 무엇입니까?


5

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 ()로 로그가 조각화되지 않았는지 확인하십시오. 다시 그리고 그들이 있다면, 그들은 많이 자랐 음을 의미합니다. 다음을 사용하여 로그 파일 축소 및 재 확장이 방법 .


2

스토리지 요구 사항을 평가하고 하드웨어 / 호스팅 서비스를 적절히 계획하는 데 걸리는 시간 내에 서버가 중단되지 않도록 충분히 축소해도됩니다 (질문 4 참조). 아니요, 잠그지 않습니다. 제한 사항을 참조하십시오 . 데이터베이스는 단순하게 유지되므로 축소합니다.

연구를 수행하고 계획을 작성하기 위해 전문 지식을 계약하는 것이 좋습니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.