MSSQL RECOVERY 옵션

타 팀에서 서비스 중인 DB 중 트랜잭션 로그 백업 처리 스케쥴을 등록하지 않아 디스크 용량이 0이 되버려서 이러지도 저러지도 못하는 경우가 있어 처리해준게 벌써 두 번째. 

 

RDBMS에서 기본 복구 모델 설정은 보통 full로 되어 있기 때문에 Management studio에서 축소 처리를 해도 백업 전에는 줄어들지 않습니다. 

 

DB 관리를 위해 트랜잭션 파일 옵션에 대해서는 두 가지를 신경써야 합니다. 

 

1. 사고 발생 시 복구가 필요한 DB 인가.. 

 

중요한 정보가 기록되고 사고 발생 시 분 단위로 정보를 복구해야 하는지를 생각해서 꼭 필요한 경우 full로 그렇지 않고 하루 혹은 주 단위로 전체 백업을 한 파일로 복구 하거나 혹은 분실되도 상관없는 DB는 simple로 설정하는게 좋습니다. 

 

2. 스케쥴러에 정기적으로 백업하는 옵션 설정. 전체 백업 주기에 맞춰 자동으로 삭제.

 

트랜잭션 로그는 정기적으로 백업을 해서 파일 크기를 일정하게 유지하는게 좋습니다. 그리고 전체 백업 파일이 생성되는 시점 이전의 트랜젝션 로그들은 존재 의미가 없습니다. 

 

예를들어 매주 월요일 0시에 전체 백업을 한다면 그 이전에 생성된 트랜젝션 로그 파일들은 자동 삭제되도록 설정하는게 좋습니다.

 

만약 최신 데이터 뿐만 아니라 1년전 정보를 특정 시간 간격 단위로 복구해야 한다면 그 기간안에 백업된 파일들은 유지해야겠죠.

 

 

그리고 간혹 트랜잭션 로그가 별 의미없는 DATABASE를 만들어 사용하는 경우가 있습니다. 

 

테스트 DB용, 로그 DB 등 ... 

 

테스트 DB의 경우 일정 기간 사용 후 삭제한다면 모를까.. 지속적으로 사용할 경우 트랜잭션 로그 설정을 잊지 말아야 합니다. 

 

로그  DB를 RDBMS에 기록한다는게 아이러니 하지만... 써야만 하는 상황이라면... 복구 옵션을 simple로 두고 문제 발생 시 언제든 삭제되도록 하는게 좋습니다. 

 

 

[복구 모델 변경 쿼리]

USE myDBName;
ALTER DATABASE myDBName SET RECOVERY FULL;   -- 쿼리 하나하나를 확인하며 복구가 필요한 경우
ALTER DATABASE myDBName SET RECOVERY SIMPLE;

[로그 파일 삭제]

DBCC SHRINKFILE (myDBName_log, TRUNCATEONLY)

파일 축소 시 DB 명은 select * from sys.database_files 로 타겟 DB명을 확인하세요. 일반적으로 트랜잭션 로그 파일은 DB명 뒤에 _log가 붙어 있습니다.