전체 백업 후 트랜잭션 로그 백업 크기를 줄이려면 어떻게합니까?

Sql Server 2005 인스턴스에서 실행되도록 세 가지 유지 관리 계획이 있습니다.

• 주간 데이터베이스 최적화 및 전체 백업
• 매일 차등 백업
• 시간별 트랜잭션 로그 백업

시간별 로그 백업은 일반적으로 활동 수준에 따라 수백 Kb에서 10Mb 사이이며 일주일이되면 주말까지 약 250Mb로 증가하고 주별 백업은 약 3.5Gb입니다.

내가 가진 문제는 전체 백업 이전의 최적화로 인해 다음 트랜잭션 로그 백업이 정상으로 돌아 오기 전에 전체 백업 크기 (이 경우 8Gb)의 2 배 이상으로 커지는 것 같습니다.

이외의 경우 BACKUP LOG <DatabaseName> WITH TRUNCATE_ONLY, 로그 백업의 크기를 줄이거 나 최적화가 트랜잭션 로그에 전혀 기록되지 않도록하는 방법이 있습니까?

로그 백업의 작동 방식에 대한 오해가있는 것처럼 보이는 몇 가지 흥미로운 제안이 있습니다. 로그 백업에는 중간에서 수행 된 전체 또는 차등 백업에 관계없이 이전 로그 백업 이후 생성 된 모든 트랜잭션 로그가 포함됩니다. 로그 백업을 중지하거나 매일 전체 백업으로 이동해도 로그 백업 크기에는 영향을 미치지 않습니다. 트랜잭션 로그에 영향을 미치는 유일한 것은 로그 백업 체인이 시작되면 로그 백업입니다.

이 규칙의 유일한 예외는 로그 백업 체인이 손상된 경우입니다 (예 : SIMPLE 복구 모델로 이동하여 데이터베이스 스냅 샷에서 복귀, BACKUP LOG WITH NO_LOG / TRUNCATE_ONLY를 사용하여 로그 자르기).이 경우 첫 번째 로그 백업 마지막 전체 백업 이후의 모든 트랜잭션 로그를 포함합니다 (로그 백업 체인을 다시 시작 함). 또는 로그 백업 체인이 시작되지 않은 경우-처음으로 FULL로 전환하면 첫 번째 전체 백업이 수행 될 때까지 일종의 유사 -SIMPLE 복구 모델로 작동합니다.

SIMPLE 복구 모델로 이동하지 않고 원래 질문에 대답하려면 모든 트랜잭션 로그를 백업해야합니다. 수행하는 작업에 따라 로그 백업을 자주 수행하여 크기를 줄이거 나 대상 데이터베이스를 더 많이 만들 수 있습니다.

수행중인 유지 보수 작업에 대한 정보를 게시 할 수 있으면 최적화하는 데 도움을 줄 수 있습니다. 우연히, 인덱스 재 구축에 사용 된 공간을 되찾기 위해 인덱스 재 구축과 축소 데이터베이스를 수행하고 있습니까?

유지 보수가 진행되는 동안 데이터베이스에 다른 활동이없는 경우 다음을 수행 할 수 있습니다.

• 사용자 활동이 중지되었는지 확인
• 최종 로그 백업 수행 (이를 통해 유지 관리 시작 시점까지 복구 할 수 있음)
  • 단순 복구 모델로 전환
  • 유지 관리 수행-각 검사 점에서 로그가 잘립니다.
  • 전체 복구 모델로 전환하고 전체 백업을 수행하십시오.
  • 정상적으로 계속

더 많은 정보를 기대하면서 이것이 도움이되기를 바랍니다.

감사

[편집 : 전체 백업이 후속 로그 백업의 크기를 변경할 수 있는지 여부에 대한 모든 논의가 끝나면 배경 자료와이를 증명하는 스크립트가 포함 된 포괄적 인 블로그 게시물을 작성했습니다. https://www.sqlskills.com/blogs/paul/misconceptions-around-the-log-and-log-backups-how-to-convince-yourself/] 에서 확인 하십시오.

축소 할 수는 있지만 다시 커져 결국 디스크 조각화가 발생합니다. 인덱스 재 구축 및 조각 모음은 매우 큰 트랜잭션 로그를 만듭니다. 특정 시점 복구 기능이 필요하지 않은 경우 단순 복구 모드로 변경하고 트랜잭션 로그 백업을 완전히 제거 할 수 있습니다.

최적화에 유지 관리 계획을 사용하고 있다고 생각합니다. 특정 조각화 수준에 도달했을 때만 인덱스 조각 모음을 수행하는 스크립트를 사용하도록 변경하여 성능 저하가 발생하지 않을 수 있습니다. 이것은 훨씬 작은 로그를 생성합니다.

일일 전체 백업 BTW를 선호하여 일일 차등을 건너 뛰겠습니다.

마지막 질문은 다음과 같습니다. "TRUNCATE_ONLY를 사용하는 백업 로그 이외의 로그 로그의 크기를 줄이거 나 트랜잭션 로그에 최적화가 전혀 기록되지 않도록하는 방법이 있습니까? 백업보다 먼저? "

아니요, 그러나 해결 방법이 있습니다. 당시 해당 데이터베이스의 유일한 활동이 인덱스 유지 보수 작업이라는 것을 알고 있으면 인덱스 유지 보수가 시작되기 전에 트랜잭션 로그 백업을 중지 할 수 있습니다. 예를 들어 토요일 밤에 내 서버 중 일부의 작업 일정은 다음과 같습니다.

• 오후 9:30-트랜잭션 로그 백업이 실행됩니다.
• 오후 9:45-트랜잭션 로그 백업이 마지막으로 실행됩니다. 스케줄은 9:59에 멈 춥니 다.
• 오후 10시-인덱스 유지 보수 작업이 시작되고 11:30 전에 내장 중지 기능이 종료됩니다.
• 오후 11시 30 분-전체 백업 작업이 시작되고 30 분 이내에 완료됩니다.
• 오전 12:00-15 분마다 트랜잭션 로그 백업이 다시 시작됩니다.

즉, 오후 9시 45 분에서 오후 11시 30 분 사이의 특정 시점 복구 기능은 없지만 성능은 더 빠릅니다.

쉬운 답변 : 주간 최적화 작업을 야간에보다 균형 잡힌 방식으로 실행하도록 변경하십시오. 즉, 일요일 밤에 테이블 ae, 월요일 밤에 f-l 등을 다시 색인화합니다. 균형이 잘 잡히면 로그의 평균 크기는 대략 1/6입니다. 물론 내장 ssis 인덱스 유지 관리 작업을 사용하지 않는 경우에 가장 효과적입니다.

이것의 단점은 DB 경험 부하에 따라 중요하며 최적화 프로그램과 쿼리 계획의 재사용으로 혼란을 겪습니다.

그러나 주 단위로 t-log의 크기 만 신경 쓰면 매일 매일 또는 시간 단위로 분할하고 t-log 백업을 중간에 실행하십시오.

또한 백업 및 로그의 크기를 줄이기 위해 타사 도구 (Quest의 Litespeed, Red Gate의 SQL 백업, Hyperbac)를 살펴볼 수도 있습니다. 테이프 절약으로 빠르게 비용을 지불 할 수 있습니다.

"최적화"에 인덱스 재 구축이 포함되어 있다고 가정 할 수 있습니다. 대량의 업데이트 및 삽입이 발생하지 않는 데이터베이스에서는 주 단위로 이러한 작업을 수행하는 것이 허용 될 수 있지만 데이터가 유동적이면 몇 가지 작업을 수행 할 수 있습니다.

1. 일정이 허용되고 영향을받을 수있는 경우 야간에 색인을 다시 작성하거나 재구성하십시오. 이러한 야간 인덱스 유지 관리 작업을 수행 할 때는 재 구축의 경우 30 %를 초과하고 reorgs의 경우 15-30 % 범위에서 조각화 된 인덱스 만 대상으로합니다.

2. 이러한 작업은 기록 된 트랜잭션이므로 로그 증가에 대해 염려되는 경우 Paul이 권장하는 사항을 옹호합니다. 인덱스 유지 관리 이전의 최종 트랜잭션 로그 백업은 단순 복구로 전환 한 다음 유지 관리 프로세스로 전환 한 다음 전체 복구로 다시 전환 한 다음 전체 데이터 백업으로 전환하여 트릭을 수행해야합니다.

로그 파일에 대해 zen과 유사한 접근 방식을 사용합니다. 원하는 크기입니다. 내가 사는 만트라 인 데이터베이스 활동과 비교할 때 백업 관행이 열악하여 과도한 성장을 견뎌 내지 않는 한

임의 인덱스 유지 관리를 수행하는 스크립트는 온라인 상태입니다. Andrew Kelly는 약 ​​1 년 전에 SQL Magazine에 적절한 기사를 게시했습니다. SQLServerPedia는 Michelle Ufford의 일부 스크립트를 가지고 있으며 SQL Magazine의 최신호 (2009 년 7 월)는이 주제에 대한 전체 기사를 제공합니다. 요점은 자신에게 가장 잘 맞는 것을 찾아 최소한의 사용자 지정으로 자신만의 것을 만드는 것입니다.

데이터베이스 최적화 중에 다양한 시점에서 트랜잭션 로그를 특별히 백업 할 수 있습니까? t- 로그의 총 크기는 동일하지만 각각 작은 크기이므로 약간의 도움이 될 수 있습니다.

더 많은 대상 데이터베이스 최적화를 수행하여 더 적은 수의 트랜잭션이 작성되도록 할 수 있습니까 (누군가 언급했지만 그 의미가 확실하지는 않습니다). 일정량의 조각화 또는 한동안 낭비되는 공간을 견딜 수 있습니다. 테이블의 40 %가 5 % 만 조각난 경우 테이블을 건드리지 않으면 약간의 활동이 절약 될 수 있습니다.