MSSQL DB 서버를 운영하다면 보면 가끔 이 LDF 파일의 용량이 쓸데 없이 비대해 지는 경우가 있다. 주기적으로 트랜잭션로그를 백업해 주지 않았거나 또는 백업 스케줄이 실패하여 몇 차례 주기 분에 대한 데이타가 고스란히 쌓였기 때문이다. LDF 파일의 용량이 비대해 지면 서버 관리자의 마음도 착찹해지지만, MSSQL 서비스도 힘들어 한다. DB 액세스가 일어날 때마다 그 큰 용량의 파일을 읽고 써야하니 얼마나 곤욕스럽겠는가?
뒤늦게 LDF 파일의 용량이 비정상적으로 비대해 졌음을 확인하고, 트랜잭션로그를 백업해봐도 할당량으로 인해 몸집이 커진 LDF 파일은 속은 깨끗이 비웠음에도 불구하고, 정작 중요한 파일 용량이 줄어들지 않는다. 그래도 이건 양반이다. 일단 LDF 파일의 용량이 기가바이트 단위에서 놀기 시작하여 트랜잭션로그 백업은 엄두도 내지 못 한다. 기가바이트 단위의 파일을 백업하게 되니 엄청난 I/O가 발생할 수밖에 없고, 언제 백업이 완료될지 그 끝을 알 수 없다.
위와 같은 상황이 도래했다면 Truncate_only 옵션을 이용해 트랜잭션로그를 백업하고, Shrinkfile 명령어를 통해 LDF 파일의 용량을 수동으로 다이어트 시켜 주어야 한다.
우선 Truncate_only 옵션으로 트랜잭션로그를 백업하는 쿼리는 다음과 같다.
| use master
backup log DB명 with Truncate_only |
Truncate_only 옵션을 사용하며 단어 뜻 그대로 별도의 백업 파일을 남기지 않고, LDF 파일의 실제 내용을 잘라낸다. 하지만 이 백업 명령어만으로는 이미 LDF 파일에 할당된 할당 용량까지는 줄일 수 없다.
다음은 shrinkfile 명령어를 통해 LDF 파일의 용량을 수동으로 축소시키는 쿼리다.
| use DB명
dbcc shrinkfile(로그파일논리명, 축소할 용량) |
이해를 돕기 위해 예제를 만들어 보자면 다음과 같다.
| use nice19
dbcc shrinkfile(nice19_log, 10) |
참고로 축소할 용량은 MB 단위이며 로그파일의 논리적 명칭은 아래와 같은 쿼리로 확인할 수 있다.
위의 쿼리를 실행시켰을 때 '이름(name)' 컬럼에 표기되는 것이 바로 논리적 명칭이다. 모든 작업이 완료되었다면 실제로 LDF 파일의 용량이 줄어들었는지 확인해 보도록 한다.
끝으로 가장 중요한 것은 LDF 파일 용량이 비대해 지기 전에 트랜잭션로그 백업 스케줄을 설정하여 미련에 방지하는 것이다. 개인적으로 트랜잭션로그의 경우, DB 액세스 량에 따라 3일 또는 1주 단위로 백업 스케줄을 설정해 주는 것이 가장 적절하다고 생각한다.
ps. 귀찮은 관계로 이번에는 SQL 파일 다운로드를 제공하지 않습니다. -_-…