데이터베이스 ‘DB NAME’의 트랜잭션 로그가 ‘LOG_BACKUP’ (으)로 인해 꽉 찼습니다.

서버 용량 초과로 트랜젝션이 정상적으로 작동하지 않는 경우이다.

실제로 이를 확인 하기 위해선 SSMS 로 MSSQL 서버에 접속한 다음, DB 우클릭 → 속성 → 일반 으로 가면 실제 DB의 용량을 확인 할 수 있으며, 해당 DB 파일이 어디에 저장되어지는지는 DB 우클릭 → 속성 → 파일 로 이동하면 DB 와 DB 로그 파일이 어디 경로에 저장되는지 알 수 있다.

실제로 DB 가 저장된 하드의 용량이 부족하다는 것을 알 수 있다.

그럼 어느 DB 가 용량을 많이 차지하는지 확인을 해야하는데 이는 여러 방법이 있지만 쿼리를 이용해 확인하는 방법은 다음과 같다.

WITH fs
AS
(
    SELECT database_id, TYPE, SIZE  , name 
    FROM sys.master_files
)
SELECT 
    name,
    (SELECT SIZE FROM fs WHERE TYPE = 0 AND fs.database_id = db.database_id) DataFileSize,
    (SELECT SIZE FROM fs WHERE TYPE = 1 AND fs.database_id = db.database_id) LogFileSize
FROM sys.databases db

sys.master_files 에서 모든 db 파일들을 조회하고, sys.databases 에서 조회된 데이터베이스들의 id 와 매칭시켜 각 DB 사이즈를 알려주는 쿼리이다. 이 경우 type = 0 이면 실제 DB, type = 1 이면 DB LOG 이다.

위와 같은 결과를 얻게 되는데 현재 특정 DB 에서 로그 크기가 많이 차지하는 걸 알 수 있다.

USE [Database];
GO
-- Truncate the log by changing the database recovery model to SIMPLE.
ALTER DATABASE [Database]
SET RECOVERY SIMPLE;
GO
-- Shrink the truncated log file to 100 MB. 
DBCC SHRINKFILE ([Database_Log], 100);
GO
-- Reset the database recovery model.
ALTER DATABASE [Database]
SET RECOVERY FULL;
GO

위 쿼리를 이용하면 해결 가능하다.

해석하면 선택한 DB 의 복구 모델을 SIMPLE 로 변경하여 로그를 삭제하고, 로그 최대 크기를 100MB 로 변경한다음 복구 모델을 다시 FULL 로 설정하는 쿼리이다.

이후 DB 사이즈를 확인해보면 줄어든 모습을 볼 수 있다.