구성 데이터가 들어있는 데이터베이스가 있습니다. 응용 프로그램이 실행될 때 기본적으로 많은 계산을 수행 한 다음 일부 데이터를 파일에 씁니다. 일반적인 설치와 달리 우리는 실제로 트랜잭션 로그가 필요하지 않습니다. 여기서 우리가 의미하는 바는 데이터베이스를 백업하고 트랜잭션 로그를 적용하지 않고 데이터베이스를 사용하여 최신 상태로 유지할 수 있다는 것입니다.데이터 복구가 중요하지 않은 경우 트랜잭션 로그 백업
트랜잭션 로그가 우리에게 중요하지 않으므로 최선의 백업 전략은 무엇입니까? 현재 트랜잭션 로그는 엄청납니다 (10GB는 데이터베이스가 약 50MB이므로 몇 달이 넘었습니다).
우리는 단지 데이터베이스의 초기 백업을 수행 한 다음 며칠 또는 그 이하의 트랜잭션 로그를 백업하여 현재 로그를 덮어 쓸 수 있습니까? 또는 트랜잭션 로그를 모두 삭제하고 새 트랜잭션 로그를 시작할 수 있습니까?
JD.
감사합니다. 간단히 요약하면 간단합니다. 그러나 우리는 데이터베이스에 데이터를 쓰지 만이 데이터는 백업 된 데이터베이스에서 계산할 수 있습니다. 링크에는 데이터가 변경되지 않는 데이터베이스에 대해 Simple이 좋다고 언급되어 있습니다. 필자는 구성 데이터를 변경할 때 전체 데이터베이스 백업 만 필요하다고 가정합니다. 이 작업을 자동화하고 트랜잭션 로그 축소와 같은 다른 작업을 수행 할 수 있습니까? JD. –
방금 더 많은 독서를했습니다. SQL Server 인스턴스의 복구 간격은 0 분입니다. 내가 아는 바로는 자동 체크 포인트가 발생합니다. 즉, 트랜잭션 로그가 잘 리므로 재사용 공간이 확보됩니다. 이 올바른지? 그렇다면 실제로 스크립트를 실행할 필요가 없습니다 (전체 데이터베이스 백업 만). –
@JD : 단순 복구 모델을 사용한다는 것은 필요에 따라 데이터베이스를 특정 시점으로 복구 할 수 없다는 것을 의미합니다 (트랜잭션 로그 백업이 필요하기 때문에). 제공된 특정 시점 복구는 요구 사항이 아니며, 아마도 데이터는 비교적 정적이거나 다른 수단, 예를 들어 다른 수단에 의해 복구 될 수있다. 전체 데이터베이스 백업이 있거나 데이터 피드를 다시 가져올 때 데이터를 복구 할 수있는 경우 Simple Recovery Model이 사용자의 필요에 맞습니다. 또한 단순 복구 모델이 자동으로 트랜잭션 로그 파일의 자르기를 관리한다는 점에서 옳습니다. –