배경

단순 복구 모델의 DB에서 트랜잭션 로그가 계속 비대해 드라이브 용량이 박박한 사건이 발생했습니다.
단순 복구 모델은 업데이트가 완료되면 로그가 잘리므로 전체 복구 모델과 비교할 때 로그 비대는 발생하기 어려운 복구 모델입니다.
원인 조사와 해결까지의 흐름을 소개하고 싶습니다.

조사

1. 왜 로그가 잘리지 않는지 확인

select * from sys.databases

sys.databases 의 log_reuse_wait_desc를 확인하면 로그가 잘릴 수 없는 원인을 알 수 있습니다.
이번에는 "ACTIVE_TRANSACTION"이었습니다.
이것은 이름에서 알 수 있듯이 활성 트랜잭션이 계속 존재하기 때문입니다.
이 시점에서 어떤 쿼리가 구체적인 원인인지는 알 수 없습니다.

2. 어떤 쿼리가 원인인지 확인

dbcc opentran

dbcc opentra 을 실행하면 트랜잭션 로그에 있는 가장 오래된 활성 트랜잭션에 대한 정보를 얻을 수 있습니다.

SPID=160이라는 세션 ID를 얻을 수 있었습니다.

3. 세션 정보 확인

select 'kill ' + cast(session_id as varchar) as command, session_id, status, cpu_time, memory_usage, reads, logical_reads, writes, last_request_start_time, last_request_end_time, 'dbcc inputbuffer(' + cast(session_id as varchar) + ')' as showquery_command, client_interface_name, program_name
from sys.dm_exec_sessions
where session_id in (160)

1: 해당 세션은 status=sleeping으로 현재는 실행되고 있지 않은 것 같습니다.
2: 해당 세션의 리소스 사용 상황(CPU 등)은, 몇번 상기 쿼리를 실행해도 변화가 없었습니다.

이상의 결과를 바탕으로 해당 세션을 KILL했습니다.

4. 상황 확인

KILL 완료 후 dbcc opentran해도 활성 트랜잭션이 사라졌습니다.

또한 트랜잭션 로그도 잘리고 용량의 박멸이 해소되었습니다.

요약

단순 복구 모델로 로그가 비대했을 때의 조사의 흐름과 해소 방법의 일례를 소개했습니다.
우선은 sys.databases의 「log_reuse_wait_desc」를 확인하는 곳에서 시작해, 그 후의 조사 방침을 결정하는 것이 좋을 것 같습니다.