트랜잭션 로그 축소

트랜잭션 로그 파일에 있는 사용하지 않는 공간이 이후에 필요하지 않다면 트랜잭션 로그의 크기를 줄여 남는 공간을 회수할 수 있는데, 이 프로세스를 로그 파일 축소라고 합니다.

축소는 데이터베이스가 온라인 상태이고 최소한 하나의 가상 로그 파일이 비어 있는 경우에만 발생할 수 있습니다. 경우에 따라 다음에 로그가 잘릴 때까지 로그를 축소하지 못할 수도 있습니다.

[!참고]

일반적으로 로그 잘림은 데이터베이스가 백업될 때는 단순 복구 모델에서, 트랜잭션 로그가 백업될 때는 전체 복구 모델에서 자동으로 발생합니다. 그러나 로그 잘림은 여러 요소로 인해 지연될 수 있습니다. 자세한 내용은 로그 잘림을 지연시킬 수 있는 요소를 참조하십시오.

로그 파일을 축소하려면(데이터베이스 파일의 축소 없이)

로그 파일 축소 이벤트를 모니터링하려면

To monitor log space

[!참고]

데이터베이스 및 로그 파일 축소는 자동으로 발생하도록 설정할 수 있습니다. 그러나 자동 축소는 사용하지 않는 것이 좋으며 autoshrink 데이터베이스 속성도 기본적으로 FALSE로 설정됩니다. autoshrink를 TRUE로 설정하면 파일 공간의 25% 이상이 사용되지 않을 때만 자동 축소에 의해 파일 크기가 줄어듭니다. 파일은 파일의 25%만 사용되지 않을 때의 크기 또는 파일의 원래 크기 중 더 큰 크기로 축소됩니다. autoshrink 속성의 설정을 변경하는 방법은 옵션 페이지의 자동 축소 속성을 사용하는 방법: 데이터베이스의 속성 보기 또는 변경(SQL Server Management Studio) 또는 AUTO_SHRINK 옵션을 사용하는 ALTER DATABASE SET 옵션(Transact-SQL)을 참조하십시오.

로그 파일 축소 작업 방법

트랜잭션 로그를 축소하면 비활성 가상 로그 파일이 하나 이상 제거되어 실제 크기가 줄어듭니다. 크기 축소 단위로는 항상 가상 로그 파일 크기가 사용됩니다. 예를 들어 6개의 100MB 가상 로그로 나뉜 600MB의 로그 파일이 있는 경우 로그 파일 크기를 100MB 단위로만 줄일 수 있습니다. 파일 크기를 500MB 또는 400MB 등의 크기로 줄일 수 있지만 433MB 또는 525M 등의 크기로 줄일 수는 없습니다. 모든 활성 로그 레코드를 포함하는 가상 로그 파일인 활성 가상 로그 파일은 논리 로그의 일부로 제거할 수 없습니다. 자세한 내용은 트랜잭션 로그 물리 아키텍처를 참조하십시오.

[!참고]

로그 파일이 생성되거나 확장될 때 데이터베이스 엔진에서 동적으로 가상 로그 파일의 크기를 선택합니다. 자세한 내용은 트랜잭션 로그 물리 아키텍처를 참조하십시오.

로그 파일의 현재 크기는 가상 로그 파일에 사용되는 페이지의 전체 크기와 같습니다. 그러나 이러한 페이지는 로그 파일에 사용되지 않습니다. 논리 로그 부분이 포함된 가상 로그 파일에 대한 공간을 확보할 수 없습니다. 로그 파일의 모든 가상 로그 파일에 논리 로그 부분이 포함되어 있으면 파일을 축소할 수 없습니다. 로그 잘림에서 하나 이상의 가상 로그 파일을 비활성으로 표시한 후에만 축소가 가능합니다.

파일 축소 작업은 비활성 가상 로그 파일만 제거할 수 있습니다. 대상 크기를 지정하지 않으면 파일 축소 작업에서 파일의 마지막 활성 가상 로그 파일을 초과하는 비활성 가상 로그 파일만 제거합니다. 대상 크기를 지정하면 지정된 파일 축소 작업에서 대상 크기에 가깝지만 이를 초과하지 않는 개수만큼만 비활성 가상 로그 파일을 제거합니다. 축소한 후의 로그 파일은 일반적으로 대상 크기보다 더 크며 더 작은 경우는 없습니다. 가상 로그 파일을 사용하면 로그 파일의 실제 축소량을 예측하기가 어렵습니다.

파일이 축소되면 파일 끝에서부터 공간이 확보됩니다. 트랜잭션 로그 파일이 축소되면 사용자가 요청한 크기로 로그를 줄이는 데 충분한 만큼 로그 파일 끝의 가상 로그 파일에 대한 공간이 확보됩니다. 사용자가 지정한 target_size는 그 다음으로 가장 높은 가상 로그 파일 경계값으로 올림됩니다. 예를 들어 사용자가 6개의 100MB의 가상 로그 파일이 포함된 600MB의 예제 파일에 대해 target_size를 325MB로 지정하면 마지막 두 개의 가상 로그 파일이 제거되고 새 파일 크기는 400MB가 됩니다.

DBCC SHRINKDATABASE 또는 DBCC SHRINKFILE 작업은 실제 로그 파일을 요청한 크기로 즉시 줄입니다.

  • 가상 로그 파일에 target_size 표시 밖으로 넘어가는 논리 부분이 없으면 target_size 표시 다음의 가상 로그 파일에 대한 공간이 확보되고 메시지 없이 DBCC 문이 성공적으로 완료됩니다.

가상 로그에 target_size 표시 밖으로 넘어가는 논리 부분이 있으면 SQL Server 데이터베이스 엔진에서 가능한 많은 공간을 확보하고 정보 메시지를 표시합니다. 이 메시지는 파일 끝의 가상 로그에서 논리 로그를 제거하는 데 필요한 동작을 알려 줍니다. 이 동작을 수행한 후에는 DBCC 문을 다시 실행하여 남은 공간을 확보할 수 있습니다.

예를 들어 가상 로그 파일이 6개인 600MB 로그 파일에 가상 로그 3에서 시작하고 가상 로그 4에서 끝나는 논리 로그가 있는 경우 target_size를 가상 로그 3의 3분기인 275MB로 지정하여 DBCC SHRINKFILE 문을 실행한다고 가정합니다.

축소 전에 6개의 가상 로그 파일이 있던 로그 파일

가상 로그 파일 5와 6은 논리 로그 부분을 포함하지 않으므로 즉시 공간이 확보됩니다. 지정한 target_size에 맞추기 위해서는 가상 로그 파일 4도 공간이 확보되어야 하지만 이 로그는 논리 로그의 끝 부분을 포함하므로 공간이 확보될 수 없습니다. 데이터베이스 엔진에서 가상 로그 파일 5와 6에 대한 공간을 확보한 후 더미 레코드로 가상 로그 파일 4의 남은 부분을 채웁니다. 이렇게 하면 로그 파일의 끝이 가상 로그 파일 1의 끝이 됩니다. 대부분의 시스템에서 가상 로그 파일 4에서 시작하는 모든 트랜잭션은 수 초 안에 커밋됩니다. 즉, 로그 파일의 전체 활성 부분이 가상 로그 파일 1로 이동되어 로그 파일이 다음과 유사해집니다.

4개의 가상 파일로 축소된 로그 파일

또한 DBCC SHRINKFILE 문은 요청된 모든 공간을 확보할 수 없으며 사용자가 BACKUP LOG 문을 실행하여 남은 공간을 확보할 수 있음을 나타내는 정보 메시지를 표시합니다. 로그의 활성 부분이 가상 로그 파일 1로 이동한 후 BACKUP LOG 문이 가상 로그 파일 4에 있는 전체 논리 로그를 자릅니다.

로그 잘라내기 이후의 로그 파일

이제 가상 로그 파일 4에는 논리 로그 부분이 없으므로 target_size를 275MB로 지정하여 같은 DBCC SHRINKFILE 문을 실행할 수 있습니다. 그러면 가상 로그 파일 4에 대한 공간이 확보되고 실제 로그 파일 크기가 요청한 크기로 줄어듭니다.

[!참고]

장기 실행 트랜잭션 같은 특정 요소는 오랜 시간 동안 가상 로그 파일을 활성 상태로 유지할 수 있습니다. 이 경우 로그 축소가 제한되거나 로그를 전혀 줄이지 못할 수 있습니다. 자세한 내용은 로그 잘림을 지연시킬 수 있는 요소를 참조하십시오.