데이터베이스를 초기 크기 아래로 축소

30GB의 라이브 사본 인 SQL Server 2005 dev 데이터베이스가 있습니다. 개발에 필요하지 않은 일부 데이터를 삭제하여 사용 된 데이터 파일 공간을 20GB로 줄였습니다. 따라서 약 33 %의 미사용 제품이 있습니다.

공간을 되 찾을 필요가 있는데, 이는 서버에 두 번째 dev DB를 가질 수있게 해줍니다. 그러나 공간을 되 찾을 수 없으며 다음을 수행했습니다.

• 파일의 초기 크기 SMS2_Data는 30GB입니다.

  DBCC SHRINKFILE (N'SMS2_Data' , 0, TRUNCATEONLY)

  뒤에

  DBCC SHRINKFILE (N'SMS2_Data' , 19500)

기쁨이 없습니다. 백업을 시도하고 초기 크기가 작은 새 DB를 만든 다음 복원을 시도했지만 초기 크기를 덮어 쓸 때 기쁨이 없습니다. 또한 시도했다 :

ALTER DATABASE SMS2HazSub MODIFY FILE (NAME = 'SMS2_Data', SIZE = 20000) 

이 오류가 발생했습니다.

파일 수정에 실패했습니다. 지정된 크기가 현재 크기보다 작습니다.

나는 20800을 시도한 다음 29000 (29GB)까지 계속 올라갔지 만 여전히 그것을 바꿀 수는 없습니다.

다음 수축을 수행에서 복구 모드로 변경 FULL을 SIMPLE하고 다시. 기쁨이 없습니다.

나는 그것이 일부 TEXT분야 와 관련이 있다고 생각했습니다 . 시스템 전체에 약 6 개가 있습니다. 테스트로 나는 그것들을 모두 버린 다음 파일을 축소했지만 여전히 변경하지 않았습니다.

남은 유일한 옵션은 데이터를 다른 DB로 다시 가져 오는 것입니다. 라이브 DB에서 수행해야하므로 위험하지 않은 실용적이지 않습니다. 라이브 DB의 사본을 반 정기적으로 가져와 개발 / 테스트를 덮어 씁니다. 500 개의 테이블이 있습니다. 데이터를 새로운 DB로 내보낼 위험이없는 방법을 원합니다.

데이터를 다른 파일로 이동하려고 시도했는데 5 %를 제외한 모든 데이터가 복사되었습니다. 이것이 모든 텍스트 열을 삭제하려고합니다.

서버가 호환 모드 90에 있지만 SP2입니다. 이제 모든 테이블 다시 색인 생성, 데이터베이스 백업, 파일 축소, 데이터베이스 축소의 3 가지 작업을 수행했습니다. 여전히 기쁨은 없습니다.

EXECUTE sp_spaceused 보고:

database_name   database_size   unallocated space
SMS2Tests       31453.94 MB     13903.16 MB

reserved     data         index_size   unused
16545568 KB  10602264 KB  4254360 KB   1688944 KB

일부 사람들은 이미 언급했듯이 기존 데이터베이스에서 새 데이터베이스를 만들고 "복사"할 수 있습니다. 이것이 최선의 선택입니다. 그러나 나는 당신이 그것을 정기적으로하고 싶다는 것을 알았습니다. 따라서 가장 좋은 옵션은 Redgate Data Compare 및 Redgate Compare 입니다. 둘 다 Redgate SqlToolbelt 패키지의 일부입니다 .

그래서 너가하는 일은:

1. 초기 크기가 작은 빈 DB를 만듭니다.
2. Redgate Compare를 사용하여 이전 DB에서 DB 구조, 함수 등을 복사하십시오.
3. Redgate Data Compare를 사용하여 기존 데이터베이스에서 새 데이터베이스로 데이터를 복사
4. 개발자 데이터베이스에서 작업 한 다음 언제든지 데이터 비교를 수행하고 개발자 DB를 정기적으로 업데이트하거나 db를 변경하면 Redgate Compare를 사용하여 변경 사항을 배포 한 다음 Redgate Data Compare를 수행 할 수 있습니다.

Data Compare의 장점은 30GB의 데이터를 복사 한 후 (일부 테이블에서만 시작할 수 있음) 잠시 후 30GB의 전체 데이터가 아닌 일부 변경 사항 만 '비교'해야한다는 것입니다. 즉, 두 데이터베이스 모두에 미치는 영향이 훨씬 적으므로 정상적으로 복사하면됩니다.

여기 몇 가지 가능성이 있습니다.

우선, SQL 2005 SP3 이상을 사용하고 있습니까? 일부는 이전 버전에서 SHRINKFILE 문제를보고했습니다 ( http://www.sqlservercentral.com/Forums/Topic981292-146-6.aspx#bm985164 참조 )

둘째, 데이터베이스가 모드 80이 아니라 모드 90 호환성으로 설정되어 있는지 확인할 수 있습니까? 이것은 SQL 2000의 문제 였지만 SQL 2005에서는 제한이 해제되었습니다. 데이터베이스가 여전히 모드 80 호환성으로 설정되어 있으면 여전히 문제가 될 수 있습니다.

셋째, LOB 데이터 (text, ntext, varchar (max))에 문제가 될 수 있습니다. 폴 랜달의 훌륭한 기사를 여기에서보십시오

SHRINKing이 실제로하는 일을 이해하고 있으며 성능에 부정적인 영향을 줄 수 있다고 가정합니다.

• SHRINK는 파일의 끝에서 처음으로 페이지를 맹목적으로 이동하여 작동합니다.
• 따라서 인덱스를 끔찍하게 조각화하여 심각한 성능 문제를 일으킬 수 있습니다.
• 이러한 데이터 집약적 인 작업으로 인해 축소에 상당한 시간이 걸릴 수 있습니다.

일반적으로 풀 리 인덱스 (방금 해제 된 일부 공간을 되 찾을 것임)로 축소를 따르는 것이 좋지만 그 시점에 도달 할 수없는 것처럼 들리지 않습니다.

활동 모니터에서 축소 SPID를 보면 아무것도하지 않는 것 같습니다. (IO 및 CPU 카운터 변경) 아니면 차단되어 있습니까? 내가 생각할 수있는 유일한 다른 것은 데이터베이스에 다른 활동이 있으면 축소를 차단하는 것입니다. 다른 활성 spid가 데이터베이스를 사용하고 있지 않은지 확인하십시오.

이 과정에서 단순 복구 모드로 전환하는 것도 로그가 너무 커지지 않도록하는 것이 좋습니다.

정말로 이것을 원한다면 :

• 복구 모드를 단순으로 설정
• 알아 두십시오 : DBCC SHRINKDATABASE (MyDatabase, TRUNCATEONLY);

SHRINKDATABASE 데이터베이스를 (최소한) MinSize로 축소하므로 도움이되지 않습니다.

기본값을 사용하여 SSMS UI를 통해 파일을 축소하려고하면 'DBCC SHRINKFILE (N'MyDB', 0, TRUNCATEONLY) '가 사용됩니다. 이 명령은 파일을 마지막 할당 된 범위까지만 줄입니다.

파일을 MinSize 아래로 축소하려면의 매개 변수 DBCC SHRINKFILE를 0에서 파일을 축소하려는 크기 (MB)로 변경하십시오. 0이 아닌 숫자는 가능하면 SHRINKFILE이 파일을 해당 크기로 줄 이도록 지시합니다. 따라서 DBCC SHRINKFILE('MyDB', 300, TRUNCATEONLY)데이터베이스 공간이 있는지 300메가바이트에 파일을 축소합니다.

다음을 실행하여 MinSize를 볼 수 있습니다.

DBCC TRACEON(3604)
go
DBCC PAGE('MyDB', 1, 0, 3) with tableresults
go

MB 단위의 MinSize는 다음과 같이 계산됩니다. (MinSize * 8) / 1024

데이터베이스에 실제 데이터의 20003 (mb)가있는 경우 "SIZE = 20000"이 너무 작습니다. 21000 또는 25000으로 시도하십시오. 작동하는지 확인하십시오. (1GB = 1024MB를 기억하십시오.)

시험

DBCC SHRINKDATABASE (N'SMS2_Data' , 0)

나는 여기에있는 SQL 2005 데이터베이스에서 이것을 사용했으며 데이터 파일에 할당 된 공간은 10.2GB에서 3GB로 줄었습니다.

참고로,이 과정은 시간이 오래 걸리며 데이터베이스에 19 분이 조금 걸렸습니다.

논리적 이름이 SMS2_Data 인 단일 데이터베이스 파일이 있다고 가정합니다. 또한 데이터베이스에 하나 이상의 트랜잭션 로그 파일이 있습니다.

현재 데이터베이스 복사본에서 해결할 수없는 문제가 있습니다. 중요한 정보는 '데이터베이스 파일의 원래 크기는 30GB입니다'입니다. 불행히도이 파일은 원래 크기보다 작게 축소 할 수 없습니다.

이미 경험했듯이 SHRINKDB와 SHRINKFILE은 원하는 것을 제공하지 않습니다. 이 명령은 원본 크기 규칙보다 축소 할 수 없습니다. 따라서 데이터베이스를 원래 크기로만 축소 할 수 있습니다.

기존의 더 작은 데이터베이스로의 데이터베이스 백업 및 복원도 작동하지 않습니다. 데이터베이스 복원을 수행하면 데이터베이스 파일이 백업 중과 같은 파일 크기로 복원됩니다. 그리고 복구 모델 (단순, 전체 등)은이 문제와 관련이 없습니다.

마지막으로 나쁜 소식이 있습니다. 더 작은 다른 데이터베이스 파일을 데이터베이스에 추가하고 30GB 파일에서 모든 데이터를 전송 한 다음 삭제하는 것을 고려할 수 있습니다. 불행히도 데이터베이스에서 초기 파일을 삭제할 수 없기 때문에 작동하지 않습니다.

따라서 최상의 솔루션은 데이터를 다른 데이터베이스에 복사하는 것입니다. 여기 몇 가지 옵션이 있으며 이미 알고있을 것입니다. 첫 번째 단계는 데이터 크기보다 작은 크기의 새 데이터베이스를 만드는 것입니다. 그런 다음 데이터베이스 크기를 필요한 크기로 확장 할 수 있습니다.

한 데이터베이스에서 다른 데이터베이스로 데이터를 전송하는 방법으로 SSIS를 고려할 수 있습니다. 도움이 될 데이터베이스 복사 작업을 찾을 수 있습니다. 다음 단계를 사용할 수 있습니다.

1. 원본 데이터베이스보다 작은 크기의 새 데이터베이스를 만듭니다.
2. 데이터베이스 전송 작업으로 SSIS 패키지를 설정하십시오. 온라인 전송을 사용하도록 작업을 설정하십시오.
3. SSIS 패키지를 실행하십시오.
4. SSIS 패키지는 소스 데이터베이스 크기와 일치하도록 데이터베이스 크기를 변경할 수 있습니다. 원본 파일 크기가 더 작으므로이 데이터베이스를 축소하십시오.

SSIS 전송 데이터베이스 작업 에 대한 추가 정보를 참조하십시오 .

데이터베이스에서 사용되지 않은 공간이 정상입니다.
큰 문자열 (예 : 긴 문자열)이 많은 경우 데이터 페이지에 사용되지 않은 공간이 많을 수 있습니다 (한 레코드가 일반적으로 페이지간에 분할되지 않기 때문에).
또 다른 것은 채우기 요소입니다. 처음에 클러스터 된 인덱스는 100 % 꽉 차서 후속 삽입에서 페이지 분할 (고가의 작업)을 피합니다.
데이터베이스에서 많은 데이터가 삭제 된 경우 이러한 데이터가 이전에 차지한 공간은 자동으로 회수되지 않으며 테이블에 할당 된 상태로 유지됩니다.

DBCC DBREINDEX (table_name, '', 100)데이터베이스의 모든 테이블을 호출하십시오. 100 % 채우기 비율로 모든 인덱스를 다시 작성하므로 데이터는 가능한 한 컴팩트하게 배치됩니다. 그런 다음 데이터베이스를 다시 축소하십시오.

SQL Server 데이터베이스를 축소하는 것이 번거로울 수 있음을 발견했습니다. 노래와 춤을해야 할 것 같습니다.

이것이 내가 일반적으로 수행하는 프로세스입니다.

백업 축소 데이터베이스 백업 축소 로그 및 데이터베이스 파일. 백업 마지막으로 줄어 듭니다.

나는이 과정을 마지막으로 작동시키기 위해 최대 3 번 까지이 과정을 수행해야했습니다. 우리는 사용되지 않은 공간이 98 % 인 68GB가 넘는 데이터베이스를 보유하고 있습니다. 이 노래와 춤을 여러 번 겪었지만 마침내 1GB 이하로 줄었습니다.

mdf 파일의 초기 크기를 먼저 29 000MB로 줄인 다음 닫기 적중을 감지하여 28,000으로 줄이려고 시도했을 것입니다.

30 %의 데이터를 삭제하여 데이터베이스 파일 크기를 30 % 줄일 것으로 예상하는 것은 무리가 없습니다.

데이터베이스에서 사용되지 않은 공간을 추정 할 수 있습니다.

execute sp_spaceused

데이터베이스의 맥락에서 (yourdatabaename을 사용하십시오.)
실행 결과를 게시 할 수 있습니까?

업데이트 :
관련 질문을 게시했습니다.

• 압축, 조각 모음, 공간 회수, 데이터베이스 축소 및 축소 파일