이것은 대부분의 포럼과 웹에서 일반적인 질문 인 것처럼 보이며 여기에는 일반적으로 다음과 같은 여러 형식으로 표시됩니다.

SQL Server에서-

• 트랜잭션 로그가 너무 커지는 이유는 무엇입니까?
• 내 로그 파일이 왜 그렇게 큰가요?
• 이 문제가 발생하지 않도록하는 방법은 무엇입니까?
• 근본적인 원인을 파악하고 트랜잭션 로그 파일을 정상적인 크기로 만들려면 어떻게해야합니까?

더 짧은 답변 :

오래 실행중인 트랜잭션이 실행 중이거나 (인덱스 유지 관리? 대량 일괄 삭제 또는 업데이트?) "기본"(기본적으로 의미하는 바는 아래에 있음) 복구 모드에 Full있고 로그 백업을 수행 하지 않은 것입니다 (또는 자주 복용하지 않습니다).

복구 모델 문제인 Simple경우 특정 시점 복구 및 정기 로그 백업이 필요하지 않은 경우 간단한 대답은 복구 모드 로 전환 일 수 있습니다 . 그러나 많은 사람들이 복구 모델을 이해하지 않고 대답합니다. 중요한 이유를 이해하고 무엇을하는지 결정하십시오. 로그 백업을 시작하고 Full복구 상태를 유지할 수도 있습니다 .

다른 이유가있을 수 있지만 가장 일반적입니다. 이 답변은 가장 일반적인 두 가지 이유에 대해 알아보기 시작하고 이유와 그 이유에 대한 배경 정보를 제공하고 다른 이유를 탐색합니다.

더 긴 대답 : 로그를 계속 성장시키는 시나리오는 무엇입니까? 여러 가지 이유가 있지만 일반적으로 이러한 이유는 다음 두 가지 패턴입니다. 복구 모델에 대한 오해가 있거나 오래 실행되는 트랜잭션이 있습니다. 자세한 내용은 계속 읽으십시오.

1/2 이유 : 복구 모델 이해

( 에있는 전체 복구 모드 와 촬영하지 로그 백업을 - 이것은 가장 일반적인 이유입니다 -.이 문제를하는 경험있는 사람들의 대부분 )

이 답변은 SQL Server 복구 모델에서 심층적 인 내용은 아니지만 복구 모델 주제는이 문제에 중요합니다.

SQL Server에는 세 가지 복구 모델이 있습니다 .

• Full,
• Bulk-Logged 과
• Simple.

우리는 Bulk-Logged지금은 하이브리드 모델이라고 생각할 것이며,이 모델에 속한 대부분의 사람들은 이유가 있고 복구 모델을 이해하고 있습니다.

우리가 관심을 둘과 혼란이 문제를 가진 사람들의 경우 대부분의 원인이다 Simple와 Full.

중단 : 일반적인 복구

복구 모델에 대해 이야기하기 전에 : 일반적으로 복구에 대해 이야기합시다. 이 주제에 대해 더 깊이 알고 싶다면 Paul Randal의 블로그 와 원하는만큼 많은 게시물을 읽으십시오 . 그러나이 질문에 대해서는 :

1. 충돌 / 다시 시작 복구
   트랜잭션 로그 파일의 목적 중 하나는 충돌 / 다시 시작 복구 입니다. 충돌 또는 재시작 전에 완료된 작업 (롤 포워드 / 다시 실행)과 충돌 또는 재시작 후 시작되었지만 완료되지 않은 작업 (롤백 / 실행 취소)의 롤 포워드 및 롤백 작업. 트랜잭션이 시작되었지만 완료되지 않았 음을 확인하는 것이 트랜잭션 로그의 작업입니다 (트랜잭션이 커밋되기 전에 롤백 또는 충돌 / 재시작이 발생 함). 그런 상황 에서 복구하는 동안 "이봐 요. 이건 정말 끝나지 않았습니다 . 되돌려 봅시다" 라고 말하는 것이 로그의 일 입니다. 또한 당신이 무언가를 끝내고 클라이언트 응용 프로그램이 (데이터 파일로 아직 강화되지 않았더라도) 끝났다고 말한 것을 확인하는 것은 로그의 일입니다."이봐 .. 정말 일어난 일이다. 다시 시작해 보자. 응용 프로그램이 생각한 것처럼 만들자 . " 더 많은 것이 있지만 그것이 주된 목적입니다.

2. 시간 복구에 포인트
   트랜잭션 로그 파일의 다른 목적은 우리에게 회복 할 수있는 능력 줄 수있을 것입니다 시간에 지점을 인해에 "죄송합니다"데이터베이스 또는 하드웨어 장애 발생시 복구 지점을 보장하는 데이터베이스의 데이터 및 / 또는 로그 파일 관련. 이 트랜잭션 로그에 복구를 위해 시작 및 완료된 트랜잭션 레코드가 포함되어 있으면 SQL Server는이 정보를 사용하여 문제가 발생하기 이전의 데이터베이스를 가져올 수 있습니다. 그러나 이것이 항상 우리에게 가능한 옵션은 아닙니다. 이를 위해서는 데이터베이스를 올바른 복구 모델 로 만들어야하며 로그 백업 을 수행해야합니다 .

복구 모델

복구 모델로 :

• 간단한 복구 모델
  위의 소개를 통해 Simple Recovery모델 에 대해 가장 쉽게 이야기 할 수 있습니다. 이 모델에서는 SQL Server를 말하고있다 "나는 당신이 충돌하고 다시 시작 복구를 위해 트랜잭션 로그 파일을 ... 사용에 괜찮아요" (조회 당신은 정말 거기에 선택의 여지가 없다. ACID 속성을 하고 빠르게 이해한다.) "...하지만 더 이상 해당 충돌 / 재시작 복구 목적으로 필요하지 않으면 로그 파일을 다시 사용하십시오."

  SQL Server는 Simple Recovery에서이 요청을 수신하고 복구 / 재시작 복구에 필요한 정보 만 유지합니다. 데이터가 데이터 파일로 강화 되었기 때문에 (더 많거나 적은) SQL Server가 복구 할 수 있다고 확신하면 강화 된 데이터는 더 이상 로그에 필요하지 않으며 잘림으로 표시되어 재사용됩니다.

• 전체 복구 모델을
  사용하면 Full Recovery로그 파일을 사용할 수있는 한 또는 로그 백업이 적용되는 특정 시점으로 복구 할 수 있음을 SQL Server에 알려줍니다. 이 경우 SQL Server가 단순 복구 모델에서 로그 파일을 자르는 것이 안전한 지점에 도달하면 그렇게하지 않습니다. 대신 정상적인 상황 에서 로그 백업을 수행 하거나 로그 파일 드라이브의 공간이 부족 해질 때까지 로그 파일이 계속 커지고 계속 커질 수 있습니다.

단순에서 전체로 전환하면 문제가 있습니다.

여기에 규칙과 예외가 있습니다. 장기 거래에 대해서는 아래에서 자세히 설명하겠습니다.

그러나 전체 복구 모드에 대해 명심해야 할 한 가지주의 사항은 다음과 같습니다. Full Recovery모드 로 전환했지만 초기 전체 백업을 수행 하지 않는 경우 SQL Server는 요청을 Full Recovery모델 로 하지 않습니다 . 트랜잭션 로그는 Simple전체 복구 모델로 전환하고 첫 번째를 취할 때까지 계속 작동합니다 Full Backup.

로그 백업이없는 전체 복구 모델이 잘못되었습니다.

이것이 통제되지 않은 로그 증가의 가장 일반적인 이유입니까? 답변 : 로그 백업없이 전체 복구 모드에 있습니다.

이것은 사람들에게 항상 일어난다 .

이것이 왜 흔한 실수입니까?

왜 항상 이런 일이 발생합니까? 각각의 새 데이터베이스는 모델 데이터베이스를보고 초기 복구 모델 설정을 가져 오기 때문입니다.

모델의 초기 복구 모델 설정은 Full Recovery Model누군가가 변경하지 않는 한 항상 입니다. "기본 복구 모델"은 Full입니다. 많은 사람들이이를 알지 못하고 데이터베이스를 Full Recovery Model로그 백업없이 실행 하므로 트랜잭션 로그 파일이 필요한 것보다 훨씬 큽니다. 이것이 조직과 필요에 맞지 않을 때 기본값을 변경하는 것이 중요한 이유입니다)

로그 백업이 너무 적은 전체 복구 모델이 잘못되었습니다.

로그 백업을 충분히 자주 수행하지 않으면 문제가 발생할 수 있습니다.
하루에 로그 백업을 수행하면 소리가 잘 들릴 수 있지만 복원에 필요한 복원 명령이 줄어들지 만, 위의 설명을 명심하면 해당 로그 파일은 로그 백업을 수행 할 때까지 계속 커지고 커집니다.

필요한 로그 백업 빈도를 어떻게 알 수 있습니까?

다음 두 가지를 염두에두고 로그 백업 빈도를 고려해야합니다.

1. 회복 필요 -이것이 희망적 일 것입니다. 트랜잭션 로그를 저장하는 드라이브가 손상되거나 로그 백업에 영향을 미치는 심각한 손상이 발생하면 얼마나 많은 데이터가 손실 될 수 있습니까? 해당 숫자가 10-15 분을 초과하지 않으면 토론이 끝나는 10-15 분마다 로그 백업을 수행해야합니다.
2. 로그 증가 -당일을 쉽게 다시 만들 수 있기 때문에 조직에서 더 많은 데이터를 잃어 버릴 경우 15 분보다 훨씬 적은 시간 동안 로그 백업을 수행하는 것이 좋습니다. 4 시간마다 조직이 괜찮을 수도 있습니다. 그러나 4 시간 동안 얼마나 많은 트랜잭션이 생성되는지 살펴 봐야합니다. 4 시간 동안 로그가 계속 커지도록하면 로그 파일이 너무 커 집니까? 로그 백업 시간이 너무 오래 걸리나요?

주요 이유 2/2 : 장기 거래

( "복구 모델이 정상입니다! 로그가 계속 커지고 있습니다! )

이는 제어되지 않고 제한되지 않은 로그 증가의 원인 일 수도 있습니다. 복구 모델에 관계없이 종종 "단순 복구 모델에 있습니다. 왜 로그가 계속 커지고 있습니까?"로 나타납니다.

여기에 이유가 간단합니다. SQL이 위에서 설명한대로 복구 목적으로이 트랜잭션 로그를 사용하는 경우 트랜잭션 시작으로 되돌아 가야합니다.

시간이 오래 걸리거나 많은 변경 작업을 수행하는 트랜잭션이있는 경우 아직 열려있는 트랜잭션에 있거나 해당 트랜잭션이 시작된 이후 시작된 변경 사항에 대한 검사 점에서 로그를자를 수 없습니다.

즉, 하나의 delete 문에서 수백만 행을 삭제하는 큰 삭제는 하나의 트랜잭션이며 로그는 전체 삭제가 완료 될 때까지 잘릴 수 없습니다. 에서 Full Recovery Model,이 기록됩니다 삭제하고 로그 기록이 많이 될 수 있습니다. 유지 관리 기간 동안 인덱스 최적화가 작동합니다. 또한 트랜잭션 관리가 열악하고 열린 트랜잭션을 보거나 닫지 않으면 실제로 사용자와 로그 파일이 손상 될 수 있습니다.

이러한 장기 실행 트랜잭션에 대해 어떻게해야합니까?

당신은 여기에 자신을 저장할 수 있습니다 :

• 유지 관리 또는 알려진 대규모 작업과 같은 최악의 시나리오를 고려하여 로그 파일의 크기를 올바르게 조정하십시오. 그리고 로그 파일을 키울 때 Kimberly Tripp 의이 지침 (및 그녀가 보내는 두 개의 링크)을 찾아야합니다 . 올바른 크기 조정은 여기서 매우 중요합니다.
• 거래 사용을 감시합니다. 응용 프로그램 서버에서 트랜잭션을 시작하지 말고 SQL Server와 오랫동안 대화를 시작하면 너무 오래 열려있을 위험이 있습니다.
• DML 문의 내재 된 거래 를 관찰합니다 . 예를 들면 : UPDATE TableName Set Col1 = 'New Value'거래입니다. 나는 BEGIN TRAN거기에 넣지 않았고 꼭 할 필요는 없지만 여전히 완료되면 자동으로 커밋되는 트랜잭션입니다. 따라서 많은 수의 행에서 작업을 수행하는 경우 해당 작업을보다 관리하기 쉬운 청크로 일괄 처리하고 복구 할 로그 시간을 제공하십시오. 또는 적절한 크기로 처리하십시오. 또는 대량로드 기간 동안 변경 복구 모델을 살펴보십시오.

이 두 가지 이유가 로그 전달에도 적용됩니까?

짧은 대답 : 예. 아래에 더 긴 답변이 있습니다.

질문 : "로그 전달을 사용하고 있으므로 로그 백업이 자동화됩니다. 왜 트랜잭션 로그가 계속 증가합니까?"

답 : 계속 읽으십시오.

로그 배송이란 무엇입니까?

로그 전달은 소리 그대로입니다. DR을 위해 트랜잭션 로그 백업을 다른 서버로 전달합니다. 초기화가 있지만 그 후 프로세스는 매우 간단합니다.

• 하나의 서버에서 로그를 백업하는 작업
• 해당 로그 백업을 복사하는 작업
• 대상 서버에서 복구하지 않고 ( NORECOVERY또는 STANDBY) 복원하는 작업

계획대로 진행되지 않는 경우 모니터링하고 경고해야 할 작업도 있습니다.

경우에 따라 하루에 한 번 또는 3 일마다 또는 일주일에 한 번만 로그 전달 복원을 수행 할 수 있습니다. 괜찮습니다. 그러나 모든 작업 (로그 백업 및 복사 작업 포함)에서이 변경을 수행하면 로그 백업을 수행하기 위해 항상 대기하고 있음을 의미합니다. 즉, 로그 백업없이 전체 복구 모드에 있기 때문에 로그가 많이 증가 하고 복사 할 큰 로그 파일을 의미 할 수도 있습니다. 복원 작업의 일정 만 수정하고 로그 백업 및 복사를보다 자주 수행해야합니다. 그렇지 않으면이 답변에 설명 된 첫 번째 문제가 발생합니다.

상태 코드를 통한 일반적인 문제 해결

이 두 가지 이외의 이유가 있지만 가장 일반적입니다. 원인에 관계없이 : 설명 할 수없는 로그 증가 / 잘림 부족에 대한 이유를 분석하고 원인을 확인할 수있는 방법이 있습니다.

sys.databases카탈로그 뷰를 쿼리하면 로그 파일이 자르기 / 재사용을 기다리는 이유를 설명하는 정보를 볼 수 있습니다.

log_reuse_wait이유 코드의 검색 ID로 호출 된 log_reuse_wait_desc열과 대기 이유에 대한 설명이 있는 열이 있습니다. 참고 서적 온라인 기사에는 대기에 관한 몇 가지 참고 사항이있는 대부분의 이유 (당신이 볼 수있는 이유와 우리가 설명 할 수있는 이유가 있습니다. 이탤릭체 :

• 0 = 아무것도
  아님 소리 .. 기다리면 안 됨

• 1 = 검사 점 검사 점이 수행 되기를
  기다리고 있습니다. 이런 일이 발생하면 괜찮을 것입니다. 그러나 나중에 답변이나 편집을 위해 여기를 찾아야 할 경우가 있습니다.

• 2 = 로그 백업 로그 백업
  이 수행되기를 기다리고 있습니다. 일정을 예약하면 곧 발생하거나 여기에 설명 된 첫 번째 문제가 발생하여 문제를 해결하는 방법을 알았습니다.

• 3 = 활성 백업 또는 복원
  데이터베이스에서 백업 또는 복원 작업이 실행 중입니다

• 4 = 활성 트랜잭션 로그를 백업하기 전에
  완료해야하는 활성 트랜잭션이 있습니다 ( ROLLBACK또는 - 또는 COMMIT). 이것이이 답변에 설명 된 두 번째 이유입니다.

• 5 = 데이터베이스 미러링
  고성능 미러링 상황에서 미러가 지연되거나 대기 시간이 걸리거나 어떤 이유로 든 미러링이 일시 중지됨

• 6 = 복제
  로그 판독기 에이전트가 실행되지 않는 것처럼 복제에 문제가있을 수 있습니다. 데이터베이스는 더 이상 존재하지 않는 복제로 표시되고 다른 여러 가지 이유가 있습니다. 또한이 이유를 볼 수 있으며 트랜잭션이 로그 리더에 의해 소비되는 것처럼 적절한 시간을보고 있기 때문에 완벽하게 정상입니다

• 7 = 데이터베이스 스냅 샷 생성 데이터베이스 스냅 샷을 생성
  하는 중입니다. 스냅 샷이 생성 될 때 적절한 순간을 보면이 내용이 표시됩니다

• 8 = 로그 스캔
  이 문제가 영원히 계속 발생하는 문제는 아직 발생하지 않았습니다. 충분히 길고 자주 보이면 이런 일이 발생할 수 있지만 과도한 트랜잭션 로그 증가의 원인이되어서는 안됩니다.

• 9 = AlwaysOn 가용성 그룹 보조 복제본이이 데이터베이스의 트랜잭션 로그 레코드를 해당 보조 데이터베이스에 적용합니다. 아직 가장 명확한 설명 ..

가장 많이 찬성 한 제안을 포함하여 Stack Overflow에 대한 답변에 실제로 만족하지 못 하기 때문에 Mike의 답변에 맞지 않는 몇 가지 사항이 있기 때문에 제공 할 것이라고 생각했습니다. 내 입력도 여기에 있습니다. 이 답변의 사본도 거기에 두었습니다.

로그 파일을 더 작게 만들면 예상치 못한 증가가 다시 발생할 것으로 예상되는 시나리오를 위해 예약해야합니다. 로그 파일이 다시 같은 크기로 커지면 임시로 축소하여 크게 수행되지 않습니다. 이제 데이터베이스의 복구 목표에 따라 수행해야 할 조치입니다.

먼저 전체 백업을 수행하십시오.

문제가 발생한 경우 복원 할 수 있는지 확인하지 않고 데이터베이스를 변경하지 마십시오.

특정 시점 복구에 관심이있는 경우

그리고 특정 시점 복구의 경우 전체 또는 차등 백업 이외의 다른 것으로 복원 할 수 있다는 점을 염두에 두어야합니다.

데이터베이스가 FULL복구 모드에있을 수 있습니다. 그렇지 않은 경우 다음을 확인하십시오.

ALTER DATABASE yourdb SET RECOVERY FULL;

정기적 인 전체 백업을 수행하는 경우에도 로그 백업 을 수행 할 때까지 로그 파일이 커지거나 커 집니다. 이는 디스크 공간을 불필요하게 먹지 않도록 보호하기위한 것입니다. 복구 목표에 따라 이러한 로그 백업을 자주 수행해야합니다. 예를 들어, 재난 발생시 15 분 이상의 데이터를 잃을 수있는 비즈니스 규칙이있는 경우 15 분마다 로그를 백업하는 작업이 있어야합니다. 다음은 현재 시간을 기반으로 타임 스탬프가 지정된 파일 이름을 생성하는 스크립트입니다 (그러나 유지 관리 계획 등을 사용하여이 작업을 수행 할 수도 있습니다. 유지 관리 계획에서 축소 옵션을 선택하지 않으면 끔찍합니다).

DECLARE @path NVARCHAR(255) = N'\\backup_share\log\yourdb_' 
  + CONVERT(CHAR(8), GETDATE(), 112) + '_'
  + REPLACE(CONVERT(CHAR(8), GETDATE(), 108),':','')
  + '.trn';

BACKUP LOG foo TO DISK = @path WITH INIT, COMPRESSION;

참고 \\backup_share\다른 기본 저장 장치를 나타내는 다른 시스템에 있어야한다. 이러한 머신을 동일한 머신 (또는 동일한 기본 디스크를 사용하는 다른 머신 또는 동일한 물리적 호스트에있는 다른 VM)에 백업하는 것은 실제로 도움이되지 않습니다. 머신이 고장 나면 데이터베이스가 손실 되었기 때문입니다. 그리고 백업. 네트워크 인프라에 따라 로컬로 백업 한 다음 장면 뒤의 다른 위치로 전송하는 것이 더 합리적 일 수 있습니다. 두 경우 모두 가능한 빨리 기본 데이터베이스 시스템에서 제거하려고합니다.

이제 정기적 인 로그 백업을 실행 한 후에는 로그 파일을 지금까지 해본 것보다 더 합리적인 것으로 축소하는 것이 합리적입니다. 이는 로그 파일이 1MB가 될 때까지 반복 해서 실행되는 것을 의미 하지는 않습니다SHRINKFILE . 로그를 자주 백업하더라도 발생할 수있는 동시 트랜잭션의 합계를 수용해야합니다. 로그 파일 자동 증가 이벤트는 SQL Server가 파일을 제로화해야하고 (즉석 파일 초기화가 활성화 된 경우 데이터 파일과 달리)이 과정에서 사용자 트랜잭션을 기다려야하므로 비용이 많이 듭니다. 이 재배-축소-수축-축소 루틴을 가능한 한 적게하고 싶으며 사용자가 비용을 지불하고 싶지는 않습니다.

축소 할 수 있기 전에 로그를 두 번 백업해야 할 수도 있습니다 (Robert 덕분에).

따라서 로그 파일의 실제 크기를 만들어야합니다. 여기에 아무도 당신의 시스템에 대해 더 많이 알지 않고도 그것이 무엇인지 알 수는 없지만 로그 파일을 자주 축소하고 다시 커지면 워터 마크가 아마도 가장 큰 것보다 10-50 % 높을 것입니다 . 200MB가되고 후속 자동 증가 이벤트가 50MB가되게하려면 다음과 같이 로그 파일 크기를 조정할 수 있습니다.

USE [master];
GO
ALTER DATABASE Test1 
  MODIFY FILE
  (NAME = yourdb_log, SIZE = 200MB, FILEGROWTH = 50MB);
GO

로그 파일이 현재 200MB를 초과하면 먼저이 파일을 실행해야 할 수도 있습니다.

USE yourdb;
GO
DBCC SHRINKFILE(yourdb_log, 200);
GO

특정 시점 복구에 관심이없는 경우

이 데이터베이스가 테스트 데이터베이스이고 특정 시점 복구에 관심이없는 경우 데이터베이스가 SIMPLE복구 모드 인지 확인해야 합니다.

ALTER DATABASE yourdb SET RECOVERY SIMPLE;

데이터베이스를 SIMPLE복구 모드로 설정하면 SQL Server가 로그 를 백업 할 때까지 복구 와 같이 모든 트랜잭션 의 기록을 유지하기 위해 증가하지 않고 로그 파일의 일부 (필수적으로 비활성 트랜잭션 제거)를 재사용해야합니다 FULL. CHECKPOINTevents는 로그를 제어하는 ​​데 도움이되며 CHECKPOINTs 사이에 많은 t-log 활동을 생성하지 않으면 커질 필요가 없습니다 .

다음으로,이 로그 증가는 정상적인 일상적인 사용이 아니라 비정상적인 이벤트 (예 : 연간 봄 청소 또는 가장 큰 지수 재 구축)에 의한 것인지 절대적으로 확인해야합니다. 로그 파일을 엄청나게 작은 크기로 축소하고 SQL Server가 정상적인 활동을 수용하기 위해 다시 커야한다면 무엇을 얻었습니까? 임시로 확보 한 디스크 공간을 사용할 수 있었습니까? 즉각적인 수정이 필요한 경우 다음을 실행할 수 있습니다.

USE yourdb;
GO
CHECKPOINT;
GO
CHECKPOINT; -- run twice to ensure file wrap-around
GO
-- 200 MB
DBCC SHRINKFILE(yourdb_log, 200);
GO

그렇지 않으면 적절한 크기와 성장률을 설정하십시오. 특정 시점 복구 사례의 예에 따라 동일한 코드와 논리를 사용하여 적절한 파일 크기를 판별하고 합리적인 자동 증가 매개 변수를 설정할 수 있습니다.

하고 싶지 않은 것들

• 와 로그를 백업 TRUNCATE_ONLY한 후 옵션SHRINKFILE . 우선이 TRUNCATE_ONLY옵션은 더 이상 사용되지 않으며 현재 버전의 SQL Server에서 더 이상 사용할 수 없습니다. 둘째, FULL복구 모델 인 경우 로그 체인이 손상되고 새로운 전체 백업이 필요합니다.

• 데이터베이스를 분리하고 로그 파일을 삭제 한 후 다시 첨부하십시오 . 이것이 얼마나 위험한지 강조 할 수 없습니다. 데이터베이스가 백업되지 않거나 의심스러운 것으로 표시 될 수 있으며 백업이있는 경우 백업으로 되돌려 야 할 수도 있습니다.

• "데이터베이스 축소"옵션을 사용하십시오 . DBCC SHRINKDATABASE특히 로그 문제 문제를 해결해야하는 경우에는 유지 관리 계획 옵션을 사용하는 것이 좋지 않습니다. 조정하려는 파일을 대상으로하고 DBCC SHRINKFILE또는 ALTER DATABASE ... MODIFY FILE(위의 예)를 사용하여 독립적으로 조정하십시오 .

• 로그 파일을 1MB로 줄 입니다. SQL Server가 특정 시나리오에서이를 수행하고 사용 가능한 모든 공간을 볼 수있게 해줄 것입니다. 데이터베이스가 읽기 전용이 아니라면 (을 사용하여 표시해야 함 ALTER DATABASE) 로그가 복구 모델에 관계없이 현재 트랜잭션을 수용해야하기 때문에 불필요한 증가 이벤트가 발생할 수 있습니다. SQL Server가 천천히 고통스럽게 되돌릴 수 있도록 그 공간을 일시적으로 비우는 시점은 무엇입니까?

• 두 번째 로그 파일을 작성하십시오 . 이렇게하면 디스크를 가득 채운 드라이브가 일시적으로 완화되지만 구멍이 뚫린 폐를 반창고로 고치는 것과 같습니다. 다른 잠재적 인 문제를 추가하는 대신 문제가있는 로그 파일을 직접 처리해야합니다. 일부 트랜잭션 로그 활동을 다른 드라이브로 경로 재지 정하는 것 외에 두 번째 로그 파일은 한 번에 하나의 파일 만 사용할 수 있으므로 실제로 두 번째 데이터 파일과 달리 아무 것도 수행하지 않습니다. Paul Randal은 또한 여러 개의 로그 파일이 나중에 물릴 수있는 이유를 설명합니다 .

능동적으로 행동하십시오

로그 파일을 적은 양으로 축소하고 자체적으로 작은 비율로 지속적으로 자동 증가시키는 대신, 합당한 큰 크기 (최대 동시 트랜잭션 세트의 합계를 수용 할 수있는 크기)로 설정하고 합리적인 자동 증가를 설정하십시오. 단일 트랜잭션을 만족시키기 위해 여러 번 성장할 필요가없고 정상적인 비즈니스 운영 중에 성장하는 것이 상대적으로 드물게되도록 대체로 설정합니다.

여기서 최악의 설정은 1MB 증가 또는 10 % 증가입니다. 재미있게도, 이것들은 SQL Server의 기본값입니다 (이에 대해 불평하고 novail 변경을 요청했습니다 )-데이터 파일의 경우 1MB, 로그 파일의 경우 10 %. 전자는이 날과 나이에 너무 작으며 후자는 매번 더 길고 더 긴 이벤트로 이어집니다 (예 : 로그 파일은 500MB, 첫 번째 성장은 50MB, 다음 성장은 55MB, 다음 성장은 60.5MB 등-그리고 느린 I / O에서 나를 믿으십시오. 실제로이 곡선을 알 수 있습니다).

추가 자료

여기서 멈추지 마십시오. 로그 파일 축소에 대한 많은 조언은 본질적으로 나쁘고 재앙이 될 수 있지만 디스크 공간을 확보하는 것보다 데이터 무결성에 더 관심이있는 사람들이 있습니다.

• 2009 년에 쓴 블로그 게시물에서 몇 가지 "로그 파일을 축소하는 방법"게시물이 생겼습니다 .

• 브렌트 오자 (Brent Ozar)는 4 년 전에 게시 하지 말아야 할 SQL Server Magazine 기사에 대한 답변으로 여러 리소스를 지적한 블로그 게시물을 작성 했습니다 .

• t-log 유지 보수가 중요한 이유 와 데이터 파일을 축소하지 않아야하는 이유를 설명하는 Paul Randal의 블로그 게시물 .

• Mike Walsh는 물론 로그 파일을 즉시 축소 할 수없는 이유를 포함하여 이러한 측면 중 일부를 다루는 훌륭한 답변을 제공합니다 .

로그 파일의 내용을 볼 수도 있습니다. 이를 위해 문서화되지 않은 fn_dblog또는 ApexSQL Log 와 같은 트랜잭션 로그 리더를 사용할 수 있습니다 .

그것은 인덱스 재구성을 표시하지 않습니다, 그러나 그것은 모든 DML과 다양한 DDL 이벤트를 보여줍니다 : ALTER, CREATE, DROP, 부여 / 권한, 오브젝트 이름 변경을 취소, 트리거가 활성화 / 비활성화.

면책 조항 : ApexSQL에서 지원 엔지니어로 일하고 있습니다.

이는 로그가 커지고 디스크를 채우는 거의 모든 DBA에서 가장 자주 발생하는 문제입니다.

트랜잭션 로그가 너무 커지는 이유는 무엇입니까?

1. 장기 거래
2. 인덱스 재구성, 재구성, 대량 삽입, 삭제 등과 같은 높은 로깅 트랜잭션
3. 로그를 보유하고 로그 공간을 해제 할 수없는 복제, 미러링과 같은 HA

• 내 로그 파일이 왜 그렇게 큰가요?

표 에서 log_reuse_wait_desc 열을 확인 sys.databases하여 로그가 잘리지 않도록하는 내용을 확인하십시오 .

select name, log_reuse_wait_desc 
from sys.databases

•이 문제가 발생하지 않도록하는 방법은 무엇입니까?

로그 백업은 로그 재사용을 방해하는 내용이 없으면 로그 증가를 제어하는 ​​데 도움이됩니다.

• 근본적인 원인을 파악하고 트랜잭션 로그 파일을 정상적인 크기로 만들려면 어떻게해야합니까?

실제로 원인을 식별 한 경우 아래 페이지에 설명 된대로 수정하십시오.

https://www.brentozar.com/archive/2016/03/my-favorite-system-column-log_reuse_wait_desc/

비정상적인 상황이 아닌 한 적절한 로그 백업을 예약하는 것이 로그 증가를 처리하는 가장 좋은 방법입니다.