SQL Server에서 트랜잭션 로그가 자동으로 축소됩니까?

10

단순 모드의 SQL Server 데이터베이스 인 경우 트랜잭션 로그 bakcup에 신경 쓸 필요가 없습니다. 그러나 단순 모드에서는 전체 모드에서와 같이 트랜잭션 로그가 커지는 것처럼 보입니다. 특정 시점에 자동으로 잘림이 발생합니까? 아니면 수동으로 자르거나 축소해야합니까?

— 주니어 라
소스

19

자동으로 잘리지 만 축소하는 것과는 매우 다릅니다. 잘림은 재사용을 위해 로그 공간을 회수하고, 파일 크기를 물리적으로 줄이면 공간이 OS로 다시 해제됩니다. 로그가 현재 크기로 커지면 축소하면 다시 커질 가능성이 있습니다.

시스템의 일반적인 최대 로그 사용량을 처리하는 것이 좋습니다. 아래 쿼리 (Glen Berrys DMV 스크립트에서 강화 된 것이 아니라)는 수동으로 실행되거나 에이전트 작업을 통해 테이블에 출력을 캡처 할 수 있습니다. 일주일 정도 테이블에 로그하면 일반적인 사용법과 더 중요한 점으로 인해 프로세스가 로그를 예상보다 크게 늘리는 경우를 볼 수 있습니다.

SELECT 
     db.[name] AS [Database Name]
   , db.recovery_model_desc AS [Recovery Model]
   , db.log_reuse_wait_desc AS [Log Reuse Wait Description]
   , ls.cntr_value AS [Log Size (KB)]
   , lu.cntr_value AS [Log Used (KB)]
   , CAST(
        CAST(lu.cntr_value AS FLOAT) / CAST(ls.cntr_value AS FLOAT) 
        AS DECIMAL(18,2)
     ) * 100 AS [Log Used %]
   , db.[compatibility_level] AS [DB Compatibility Level]
   , db.page_verify_option_desc AS [Page Verify Option]
   , db.is_auto_create_stats_on, db.is_auto_update_stats_on
   , db.is_auto_update_stats_async_on, db.is_parameterization_forced
   , db.snapshot_isolation_state_desc, db.is_read_committed_snapshot_on
FROM sys.databases AS db
   INNER JOIN sys.dm_os_performance_counters AS lu 
     ON db.name = lu.instance_name
   INNER JOIN sys.dm_os_performance_counters AS ls 
     ON db.name = ls.instance_name
WHERE lu.counter_name LIKE N'Log File(s) Used Size (KB)%' 
   AND ls.counter_name LIKE N'Log File(s) Size (KB)%'
   AND ls.cntr_value > 0 
OPTION (RECOMPILE);

트랜잭션 로그 잘림 은 로그 잘림이 발생하는시기와 이유를 모두 설명합니다.

트랜잭션 로그에서 로그 레코드가 삭제되지 않은 경우 실제 로그 파일에 사용 가능한 모든 디스크 공간이 채워집니다. 로그 잘림은 트랜잭션 로그에서 재사용 할 수 있도록 논리 로그의 공간을 자동으로 비 웁니다.

로그 잘림을 지연시킬 수있는 요소 는 로그 잘림 이 실패하여 예상보다 커지는 이유를 이해하는 데 유용한 참고 자료입니다.

— 마크 층-스미스
소스

4

아니 아니

축소되거나 잘리지 않습니다 (물리적 LDF 의미에서 논리적으로 수행됨)
축소하지 않도록 크기 여야합니다.

축소하면 다시 커지고 조각난 파일이 생깁니다.

— gbn
소스

0

앞에서 언급했듯이 자동 축소되지는 않습니다. 그러나 일부 쓰레기를 청소합니다.

그 이유는 전체 복구 모델에서 특정 시점 복구를 위해 tlog 백업을 수행 할 것을 SQL에 알리고 있기 때문에 데이터베이스에 대해 수행 된 모든 트랜잭션의 기록을 유지하기 때문입니다.

특정 시점 복구를 원한다고하므로 전체 백업 및 로그 백업을 수행해야합니다. tlog 백업을 완료하면 로그 내용 (꼬리 끝 제외)을 플러시하고 다시 시작합니다.

이러한 파일을 컨테이너로 생각하면 도움이 될 수 있습니다.

내 제안은 로그가 커지고 관리 할 수 없게되면 전체 백업을 잘라내는 것입니다. 로 전환 SIMPLE는 모델을 복구하고 SHRINK TLOG 파일을. 전체 복구 모델로 다시 전환하고 조각화 유지 관리 *를 수행하십시오. 다른 사람들이 게시 한 것처럼 이것은 모범 사례가 아니며 높은 수준의 조각화로 이어질 것입니다.

그 후 백업 기간을 계획하고 시작하십시오.

* 인덱스 재 구축 / 재구성 작업 및 디스크 수준 조각 모음 . 이것은 로그 유지 관리의 일부가 아닙니다. T 로그를 백업하여 유지 관리합니다. 용량에 가까워지면 자라는 용기입니다. 재 구축 / 재구성은 부적절한 로그 관리에서 복구하여 큰 드라이브 사용으로 이어질 수 있습니다.

— 라이언
소스