데이터베이스 축소
사용되지 않는 페이지를 제거하여 데이터베이스의 각 파일을 줄일 수 있습니다. 데이터베이스 엔진은 공간을 효율적으로 재사용하지만 더 이상 크게 유지될 필요가 없는 파일의 크기를 축소해야 하는 경우도 있습니다. 데이터와 트랜잭션 로그 파일을 모두 줄이거나 축소할 수 있습니다. 데이터베이스 파일을 그룹별로 또는 개별적으로 직접 축소하거나 지정된 간격에 따라 자동으로 데이터베이스가 축소되도록 설정할 수 있습니다.
항상 파일은 끝에서부터 축소됩니다. 예를 들어 5GB의 파일이 있는 경우 DBCC SHRINKFILE 문에 target_size로 4GB를 지정하면 데이터베이스 엔진은 파일의 마지막 1GB에서 비울 수 있는 만큼 공간을 비웁니다. 사용된 페이지가 해제되는 파일 부분에 있는 경우 데이터베이스 엔진은 먼저 해당 페이지를 유지되는 파일 부분에 다시 지정합니다. 남아 있는 빈 공간이 없는 상태까지만 데이터베이스를 축소할 수 있습니다. 예를 들어 5GB의 데이터베이스에 4GB의 데이터가 있는 경우 DBCC SHRINKFILE 문에 target_size로 3GB를 지정하면 1GB만 사용 가능 상태가 됩니다.
자동 데이터베이스 축소
AUTO_SHRINK 데이터베이스 옵션을 ON으로 설정하면 데이터베이스 엔진은 자동으로 빈 공간이 있는 데이터베이스를 축소합니다. 이 옵션은 ALTER DATABASE 문을 사용하여 설정합니다. 기본적으로 이 옵션은 OFF로 설정되어 있습니다. 데이터베이스 엔진은 정기적으로 각 데이터베이스의 공간 사용률을 확인합니다. 데이터베이스에서 AUTO_SHRINK 옵션을 ON으로 설정하면 데이터베이스 엔진은 이 데이터베이스의 파일 크기를 줄입니다. 이러한 작업은 백그라운드에서 실행되므로 데이터베이스 내의 사용자 작업에는 영향을 주지 않습니다.
데이터베이스를 자동으로 축소하도록 설정하려면
수동 데이터베이스 축소
DBCC SHRINKDATABASE 문 또는 DBCC SHRINKFILE 문을 사용하여 데이터베이스 또는 데이터베이스의 파일을 수동으로 축소할 수 있습니다. DBCC SHRINKDATABASE 또는 DBCC SHRINKFILE 문이 로그 파일의 지정된 모든 공간을 다시 사용할 수 없는 경우 이 문은 사용자가 더 많은 공간을 사용 가능 상태로 만들기 위해 수행해야 하는 동작을 알려주는 정보 메시지를 표시합니다. 로그 파일을 축소하는 방법은 트랜잭션 로그 축소를 참조하십시오.
DBCC SHRINKDATABASE 및 DBCC SHRINKFILE 작업은 작업 진행 중 언제든지 중지할 수 있으며 완료된 작업은 모두 그대로 유지됩니다.
DBCC SHRINKDATABASE 문을 사용하는 경우에는 전체 데이터베이스를 원래 크기보다 작게 축소할 수 없습니다. 따라서 원래 10MB로 생성된 데이터베이스가 100MB까지 증가한 경우 포함된 모든 데이터를 삭제하더라도 데이터베이스를 10MB 이하로는 축소할 수 없습니다.
그러나 DBCC SHRINKFILE 문을 사용하면 개별 데이터베이스 파일을 처음 크기보다 작게 축소할 수 있습니다. 이 경우에는 전체 데이터베이스를 한 번에 축소하는 것이 아니라 각 파일을 개별적으로 축소해야 합니다.
[!참고]
데이터베이스 또는 트랜잭션 로그를 백업하는 동안에는 데이터베이스나 트랜잭션 로그를 축소할 수 없습니다. 마찬가지로 데이터베이스 또는 트랜잭션 로그를 축소하는 동안에는 데이터베이스 또는 트랜잭션 로그 백업을 만들 수 없습니다.
데이터베이스를 축소하려면
데이터 또는 로그 파일을 축소하려면
트랜잭션 로그 축소
트랜잭션 로그 파일은 축소할 수 있는 한도가 있습니다. 로그 내에 있는 가상 로그 파일의 크기에 따라 축소 가능한 크기가 결정됩니다. 따라서 로그 파일을 가상 로그 파일의 크기보다 작게 축소할 수는 없습니다. 또한 로그 파일은 가상 로그 파일의 크기와 동일한 증분으로 축소됩니다. 예를 들어 1GB의 트랜잭션 로그 파일은 200MB의 가상 로그 파일 5개로 구성될 수 있습니다. 트랜잭션 로그 파일을 축소하면 사용되지 않는 가상 로그 파일이 삭제되지만 적어도 두 개의 가상 로그 파일은 남게 됩니다. 이 예에서는 가상 로그 파일의 크기가 각각 200MB이므로 트랜잭션 로그를 최소 400MB까지만 축소할 수 있고 200MB의 증분으로만 축소할 수 있습니다. 트랜잭션 로그 파일을 더 작은 크기로 축소하려면 한 번에 큰 트랜잭션 로그 파일을 만드는 대신 작은 트랜잭션 로그를 만들어 자동으로 증가하도록 해야 합니다.
DBCC SHRINKDATABASE 또는 DBCC SHRINKFILE 작업을 사용하면 트랜잭션 로그 파일이 반올림이 적용된 요청된 크기로 즉시 축소됩니다. 파일을 축소하기 전에 로그 파일을 백업하여 논리 로그의 크기를 줄이고 논리 로그 부분이 포함되지 않은 가상 로그를 비활성으로 표시해야 합니다. 자세한 내용은 트랜잭션 로그 축소를 참조하십시오.
최상의 방법
데이터베이스 또는 파일을 축소할 때는 다음을 고려하십시오.
축소 작업은 테이블 잘라내기 또는 테이블 삭제 작업과 같이 사용되지 않는 공간이 많이 생기는 작업이 수행된 후에 가장 효과적입니다.
대부분의 데이터베이스에는 정기적인 일상 작업에 사용 가능한 일정 공간이 필요합니다. 데이터베이스를 반복해서 축소했지만 데이터베이스 크기가 다시 늘어나는 경우 일반 작업을 위해 축소된 공간이 필요한 것입니다. 이러한 경우 데이터베이스를 반복해서 축소하는 것은 불필요한 작업입니다.
축소 작업은 데이터베이스 인덱스의 조각화 상태를 보존하지 않으며 일반적으로 조각화 정도를 어느 정도까지 늘리기도 합니다. 예를 들어 인덱스를 다시 작성한 후에는 데이터베이스나 데이터 파일을 축소하지 않아야 합니다. 이것은 데이터베이스를 반복해서 축소하지 않아야 하는 또 다른 이유입니다.
특정 요구 사항이 없을 경우 AUTO_SHRINK 데이터베이스 옵션을 ON으로 설정하지 마십시오.
행 버전 관리 기반 격리 수준 및 축소 작업
행 버전 관리 기반 격리 수준에서 실행 중인 트랜잭션에 의해 축소 작업이 차단될 수 있습니다. 예를 들어 DBCC SHRINK DATABASE 작업을 실행할 때 행 버전 관리 기반 격리 수준에서 실행 중인 대규모 삭제 작업이 진행되고 있으면 축소 작업은 파일을 축소하기 전에 삭제 작업이 완료될 때까지 기다립니다. 이러한 경우 DBCC SHRINKFILE과 DBCC SHRINKDATABASE 작업은 처음 한 시간 동안에는 5분마다 그리고 그 다음부터는 한 시간마다 SQL Server 오류 로그에 정보 메시지(SHRINKDATABASE의 경우 5202 그리고 SHRINKFILE의 경우 5203)를 인쇄합니다. 자세한 내용은 DBCC SHRINKDATABASE(Transact-SQL)를 참조하십시오.