인덱스 재 구축, DB 크기 10 배


13

약 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가 사용됩니다.

답변:


15

그 동안 나는 이것을 완전히 알아 냈습니다. 나는 재구성 작업에서 90의 채우기 비율이라고 생각한 것을 표시했지만 "여유 공간 백분율 변경"으로 표시되므로 90의 값을 사용함으로써 실제로 10의 채우기 비율을 사용하고있었습니다 !! DOH. 10 배나 커진 것도 당연합니다. 올바른 채우기 비율로 다시 빌드 한 다음 축소합니다. 입력에 대한 모든 사람에게 감사합니다.


1
이 마법사는 끔찍합니다.
usr

나는 당신이 FILL_FACTOR를 지정하고 free %가 아닌 명령 줄에 익숙해 져 일관성이 있기를 바랍니다.

다시 색인을 생성하지 말고 축소하면 시간 낭비 일뿐입니다! 자세한 내용은 내 답변을 참조하십시오.
JNK

1
JNK 나는 다시 빌드 한 후에 모든 것을 다시 조각화하기 때문에 축소하지 않는 것이 무엇인지 알고 있습니다. 그러나 Jeff가 우연히 모든 페이지에 90 %의 여유 공간을 추가 한이 특정 시나리오에서는 공간을 회수 한 다음 다른 방법으로 볼 수 없습니다 : fillfactor 90으로 다시 작성, 파일 축소, 그러나 다른 다시 작성을해야합니다 fillfactor 90 %로 다시. 또는 공간을 되 찾을 수있는 다른 방법이있을 것입니다. (아마도 새로운 파일 그룹을 만든 다음 새로운 파일 그룹으로 드롭하여 다시 작성하지만 모든 사람에게 적용되지는 않습니다.)
Edward Dortland

2

인덱스를 다시 작성하면 DB에 여유 공간이 추가로 발생합니다. 이것은 재색 인화 프로세스의 자연스러운 부산물입니다. 서버는 현재 버전과 함께 새로운, 희망적으로 인접한 색인 버전을 빌드 한 다음 완료되면 현재 버전을 삭제합니다.

재색 인화 후 축소는 의미가 없습니다!

색인을 다시 조각화하면됩니다. 축소는 DB 내에서 데이터를 재 할당하여 여유 공간을 제거합니다.

다음은 폴 랜달 (Paul Randal)의 좋은 기사이다. 마이크로 소프트에서 일할 때 DBCC축소를 포함 하여 코드를 담당 한 이유는 축소되지 않아야하는 이유이다.


0

재 구축 옵션을 사용해야합니다 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 데이터베이스 (저장 속도에 따라 다름)에서 꽤 오래 걸리므로 실행하십시오.


예, 형식이 지정되지 않습니다. 질문에 추가하겠습니다.

@JeffBane : 견적에 질문에이 정보를 추가 할 수 있습니까? 나는 거기에 무엇이 있는지 알아낼 수 없습니다.
Marcel N.

1
인덱스를 다시 작성할 때는 인덱스 공간의 두 배 + 정렬을 위해 20 %가 필요합니다. 따라서 일반적으로 DB의 모든 인덱스를 다시 작성하려면 DB에서 가장 큰 인덱스의 120 % 만 필요합니다. SORT_IN_TEMPDB를 사용하는 경우 20 % 만이기더라도 여전히 데이터 파일에 추가 100 %가 필요합니다. 또한 tempdb에서 sort를 사용하면 인덱스를 데이터 파일에 한 번 쓰는 대신 이제 tempdb에 한 번 쓴 다음 데이터 파일에 쓸 수 있으므로 IO로드가 크게 증가합니다. 따라서 항상 이상적인 것은 아닙니다.
Edward Dortland

-1

다른 세부 정보가 없으면 공간을 확보하기 전에 트랜잭션 로그 백업을 수행해야한다고 생각합니다.

일까지 select name, log_reuse_wait_desc from sys.databases알려줍니다. log_reuse_wait_desc 열에 표시 LOG_BACKUP되면 트랜 로그 백업을 완료 할 때까지 공간을 회수 할 수 없습니다.


트랜잭션 로그 백업을 수행해야한다고해서 페이지가 해제되지는 않습니다.
mrdenny
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.