약 15 기가 인 SQL Server 데이터베이스 (2008 R2 SP1)가 있습니다. 유지 관리가 한동안 실행되지 않았기 때문에 모든 인덱스를 다시 작성하는 유지 관리 계획을 만들었습니다. 매우 조각화되었습니다.
작업이 완료되고 조각화가 사라졌지 만 이제 데이터베이스가 120 기가 넘습니다! 모든 재 구축을 수행하기 위해 추가 공간을 사용했음을 알았지 만 이제 작업이 완료되었으므로 모든 공간이 여유 공간이라고 생각하지만 여유 공간은 3 기가 표시되므로 117 기가 사용됩니다. 인덱스 재구성 작업이 완료 되었어도.
나는 매우 혼란스럽고 몇 가지 지침을 사용할 수 있습니다 .DB를 합리적인 크기로 되돌릴 수 있습니다.이 디스크 공간이 없습니다.
미리 감사드립니다!
게시 된 두 쿼리의 결과는 다음과 같습니다.
log_reuse_wait_desc NOTHING
name TotalSpaceInMB UsedSpaceInMB FreeSpaceInMB
LIVE_Data 152 123 28
LIVE_Log 18939 89 18849
LIVE_1_Data 114977 111289 3688세 번째 파일은 .ndf 파일로, 사용되지 않은 공간에서는 3688 만 표시되지만 약 15 기가 바이트의 데이터에는 111289가 사용됩니다.
답변
그 동안 나는 이것을 완전히 알아 냈습니다. 나는 재구성 작업에서 90의 채우기 비율이라고 생각한 것을 표시했지만 “여유 공간 백분율 변경”으로 표시되므로 90의 값을 사용함으로써 실제로 10의 채우기 비율을 사용하고있었습니다 !! DOH. 10 배나 커진 것도 당연합니다. 올바른 채우기 비율로 다시 빌드 한 다음 축소합니다. 입력에 대한 모든 사람에게 감사합니다.
답변
인덱스를 다시 작성하면 DB에 여유 공간이 추가로 발생합니다. 이것은 재색 인화 프로세스의 자연스러운 부산물입니다. 서버는 현재 버전과 함께 새로운, 희망적으로 인접한 색인 버전을 빌드 한 다음 완료되면 현재 버전을 삭제합니다.
재색 인화 후 축소는 의미가 없습니다!
색인을 다시 조각화하면됩니다. 축소는 DB 내에서 데이터를 재 할당하여 여유 공간을 제거합니다.
다음은 폴 랜달 (Paul Randal)의 좋은 기사이다. 마이크로 소프트에서 일할 때 DBCC축소를 포함 하여 코드를 담당 한 이유는 축소되지 않아야하는 이유이다.
답변
재 구축 옵션을 사용해야합니다 SORT_IN_TEMPDB=ON.
귀하의 경우 문제의 테이블이있는 실제 데이터 파일이 인덱스 정렬에 사용되었습니다. 120GB의 많은 공간이 여전히 사용되지 않으며 필요할 때 페이지 데이터로 채워집니다.
이 쿼리에서 사용 된 / 여유 공간 상태를 확인할 수 있습니다 ( 여기 에서 가져옴 ).
use [YourDatabaseNameHere]
go
select
name,
cast((size/128.0) as int) as TotalSpaceInMB,
cast((cast(fileproperty(name, 'SpaceUsed') as int)/128.0) as int) as UsedSpaceInMB,
cast((size/128.0 - cast(fileproperty(name, 'SpaceUsed') AS int)/128.0) as int) as FreeSpaceInMB
from
sys.database_files특정 데이터베이스 파일 (데이터 또는 로그)을 축소하려면 여기에서 일부 정보를 볼 수 있습니다 . 그 전에 사용되지 않은 공간을 해제한다는 경고는 100 개 이상의 Gb 데이터베이스 (저장 속도에 따라 다름)에서 꽤 오래 걸리므로 실행하십시오.
답변
다른 세부 정보가 없으면 공간을 확보하기 전에 트랜잭션 로그 백업을 수행해야한다고 생각합니다.
일까지 select name, log_reuse_wait_desc from sys.databases알려줍니다. log_reuse_wait_desc 열에 표시 LOG_BACKUP되면 트랜 로그 백업을 완료 할 때까지 공간을 회수 할 수 없습니다.