배경:
최근 450 개 이상의 데이터베이스가있는 50 개 이상의 SQL Server를 상속했습니다. 야간 백업은 약 8TB이며 말할 필요도없이 디스크 공간을 더 많이 사용하고 있습니다. 모든 데이터베이스가 전체 복구로 설정되었으며 트랜잭션 로그가 백업되지 않았습니다. 모든 SQL Server를 살펴보고 야간 백업 만 필요하고 하루 동안의 데이터 손실이 허용되는 우선 순위가 낮은 서버를 확인했습니다.
질문:
우선 순위가 낮은 많은 데이터베이스를에서 SIMPLE복구 모드로 전환하고 FULL있습니다. 기존 트랜잭션 로그가 잘리나요 (체크 포인트가 생성 될 때)? 기존 트랜잭션 로그 중 일부는 50-100GB입니다. 앞으로 나아 가기 위해 축소해야 할 사항을 결정하는 가장 좋은 방법은 무엇입니까? 분명히 그것들을 그렇게 크게 유지하고 싶지 않습니다. 아니면 시간이 지남에 따라 스스로 축소됩니까?
답변:
로 전환하기 전에 FULL에 SIMPLE복구 모델, 당신이 손실을 감당할 수있는 데이터의 양을 스스로에게 물어. 재해가 발생한 경우 마지막 데이터베이스 백업을 복원 SIMPLE해도 괜찮은 데이터베이스의 경우 문제 가 없습니다. 그렇지 않은 경우으로 유지하십시오 FULL.
LDF파일을 가능한 한 작은 크기로 줄이려면 Kimberly Tripp에서 제공하는 단계를 수행하십시오. 트랜잭션 로그 처리량을 향상시키는 8 단계
데이터베이스에서 활동이 적은 시간을 기다리십시오.
SSMS에서 실행 :
DBCC SHRINKFILE(transaction_log_logical_filename, TRUNCATEONLY)트랜잭션 로그 파일 크기를 수정하십시오.
ALTER DATABASE db_name
MODIFY FILE ( NAME = transaction_log_logical_filename, SIZE = new_size)전체 복구 모드에서 많은 데이터베이스를 SIMPLE 복구 모드로 전환하고 있습니다 (T- 로그 및 특정 시점 복구는 필요하지 않음). 기존 트랜잭션 로그가 잘리나요 (체크 포인트가 생성 될 때)?
단순 복구 모델에서 데이터베이스 엔진은 자동 검사 점을 발행하고 빈도는 복구 간격 (고급 서버 구성 설정) 또는 로그가 70 % 가득 찼을 때 결정됩니다.
로그 잘림을 지연시키는 오래 실행되는 트랜잭션이 없으면 자동 검사 점이 T 로그의 사용되지 않은 부분을 잘립니다.
기존 트랜잭션 로그 중 일부는 50-100GB이며 앞으로 나아 가기 위해 축소해야 할 사항을 결정하는 가장 좋은 방법입니다. 분명히 그것들을 그렇게 크게 유지하고 싶지 않습니다.
50-100GB의 T- 로그가있는 데이터베이스에 대해 데이터베이스 복구 모델을 FULL로 설정 한 경우 빈번한 T- 로그 백업을 시작해야합니다. 전체 복구 모델에서 로그 백업 체인이 설정되면 자동 체크 포인트로도 로그가 잘리지 않습니다.
최후의 수단으로 로그 파일을 자른 다음 즉시 전체 백업을 수행 한 다음 T- 로그 백업을 시작하여 재해가 발생할 경우 특정 시점 복구를 수행 할 수 있습니다.
아니면 시간이 지남에 따라 스스로 축소됩니까?
@TomTom이 지적했듯이 수동 조작입니다.
읽기 :
우리는 많은 질문에 대답 할 수 없습니다. 끈의 길이는 얼마입니까?
기존 트랜잭션 로그 중 일부는 50-100GB이며 앞으로 나아 가기 위해 축소해야 할 사항을 결정하는 가장 좋은 방법입니다.
그들이 필요한 한. 나는 수축을 제안하지 않는다. 로그를 정리하고 일주일 안에 돌아와 얼마나 많은 공간이 사용되는지 확인한 다음 결정합니다. 그러나 당신은 이것에 대답해야합니다.
야간 백업은 약 8TB이며 말할 필요도없이 더 많은 디스크 공간을 사용하고 있습니다.
그렇다면 왜 그것들을 단순하게합니까? 진심으로.
모든 데이터베이스가 전체 복구로 설정되었으며 트랜잭션 로그가 백업되지 않았습니다.
약간의 논리는 igf가 한 번만 잘라 버린다고 말하면 백업을 위해 훨씬 적은 공간을 사용할 것입니다. 결과적으로 전체 복구 모드를 유지할 수 있습니다. 먼저 해보십시오. 이들이 소량 등일 경우, 로그 백업은 앞으로 훨씬 더 작아 질 것입니다.
모든 SQL Server를 살펴보고 야간 백업 만 필요하고 재해가 발생하더라도 며칠 분량의 데이터 손실이 발생하지 않는 우선 순위가 낮은 서버를 확인했습니다 (팩스 데이터베이스 및 이와 유사한 것).
예. 그것은 법정에 들어가서 중요한 법적 서류를 가지고 있지 않은 것으로 엉덩이를 손에 넣을 때까지입니다. 팩스 로그가 비즈니스 관련 정보로 몇 년 동안 보관해야 할 내용의 일부일 수 있다는 것을 알고 있습니까? 내 관할권 (10 년)에서와 같습니다. 당신이 U 주식 회사라면 비슷한 놀람 (SOX)이있을 수 있습니다. 그렇게하지 않으면 팩스를받지 못했다는 것을 증명하려는 경우 법정에서 매우 나쁘게됩니다. 아니면 하나를 보냈습니다. 이 문제가 매월 다시 발생했는지 여부는 신경 쓰지 않으며 최신 로그가 있습니다. 법 요건을 위반합니다. 중요하지 않은 비즈니스가 해고 사유 일 수 있으므로 매우 높은 누군가에 의해 서명되어 있는지 확인하십시오.
아니면 시간이 지남에 따라 스스로 축소됩니까?
그리고 그들은 그렇게하지 않아야합니다. 로그 크기 조정은 볼륨이 적은 데이터베이스를 제외한 수동 작업입니다.