최근 12 년 된 SQL 기반 응용 프로그램에서 간헐적 인 ODBC 오류의 원인을 근절해야했습니다. 범인은 저장 프로 시저 중 하나의 끝이 문장으로 밝혀졌다 :Dump TRAN의 정당한 사용
DUMP TRAN NotTheRealDBName WITH NO_LOG
I이 명령에 익숙하지 않은, 그래서 제가 조사를 좀 해봤가 트랜잭션 로그의 백업을 만드는 것을 발견 . 나는 이것이 어떤 시점에서 트랜잭션 로그를 복원 한 경우에만 유용 할 것이라고 생각한다. 문제의 저장 프로 시저는 다양한 테이블에서 삽입, 업데이트, 선택 및 삭제의 간단한 시퀀스였습니다.
비즈니스 논리의 한가운데 트랜잭션 로그를 백업하고 복원하려는 이유가 무엇인지 상상해 보려고합니다.하지만 내 마음을 알 수는 없습니다. 누구든지 덤 트란을 효과적으로 사용하는 예를 들어 줄 수 있습니까?
핵심 부분은 프로그램에 WITH NO_LOG 절이 추가된다는 것입니다. 그래서 기본적으로 로그를 자릅니다. 아마 12 년 전에 저자는 로그 성장 문제에 직면했을 것이고, '철저하게'이 문제를 연구하고 긴 업데이트를 할 때마다 로그를 자르는 것이 최선이라는 결론을 내렸다. 신경 끄시 고 그 과정에서 그는
이 명령은 데이터베이스를 축소하려는 경우에 사용됩니다. 비즈니스 논리에 사용되는 것을 본 적이 없으며 그렇게 사용하면 실제로 위험하다고 믿습니다.
DUMP 지금 BACKUP 내가이 NO_LOG 옵션은 SQL Server 2008의 중단되었습니다 확신 ... 유지 보수 계획의 백업 체인을 나누기 (좋은 원인을).
기본적으로 데이터베이스를 부적절하게 구성한 경우 - "전체"복구 모델을 사용했지만 실제로 백업을 제대로 수행하지 않은 경우 - 로그를 축소하는 방법이었습니다.
당신이 그것을 백업하지 않고 로그를 잘라 싶어 왜 거의 좋은 이유를 생각할 수 있고, 당신이 로그 를 백업 할 줄 이유는 여러 가지 이유로 생각할 수 없다비즈니스 로직의 중간이지만, 일반적으로 트랜잭션 로그를 백업하는 매우 좋은 이유가 있으며, 이는 RPO 대상을 충족시키는 것입니다.
일반적으로 하루에 하나의 데이터베이스 백업 만 수행 할 것입니다. 그러나 서버가 폭발하거나 일부 불량 DBA가 귀하의 데이터베이스를 호스 관리하는 경우 반나절 분량의 트랜잭션을 복구 할 수있는 비즈니스 요구 사항이있는 경우 프로덕션 데이터베이스 및 모든 미러를 사용하면 매시간 (또는보다 자주) 트랜잭션 로그 백업을 수행 할 수 있습니다. 그렇게하면 어제 밤 백업을 복원하고 트랜잭션 로그 백업을 사용하여 최대 1 시간 전 (또는 RPO가 무엇이든간에) 복원 할 수 있습니다.