특정 서버의 거의 모든 데이터베이스에는 전체 복구 모델이 필요하지 않으며 (트랜잭션 로그 백업은 수행하지 않음) 항상 데이터베이스를 만들고 단순 복구 모델을 지정해야합니다.
SSMS를 사용하여 많은 데이터베이스가 생성되는 경우가 종종 있습니다. 그러나 실수가 발생할 수 있으며 운영자는 단순 복구 모델을 지정하는 것을 잊을 수 있습니다. 이로 인해 며칠이 지난 후에도 잘리지 않은 3 ~ 4 개의 60GB 로그 파일로 인해 디스크 공간이 부족한 경우 "지원"이 발생합니다.
데이터베이스에서 복구 모델을 구성하여 단순 복구 모델을 새 데이터베이스의 기본 설정으로 만들 수 있습니다 model. 그러나 이것이 권장됩니까? 그렇게하면 나중에 돌아와서 어떤 식 으로든 나를 물릴 수 있습니까?
답변:
여기에 세 가지 옵션 중 하나가 있습니다.
1) 복구 모델을 명시 적으로 포함하는 데이터베이스를 작성하기 위한 템플릿 스크립트를 사용할 수 있습니다 .
2) 데이터베이스를 간단하게 설정할model 수 있으며 걱정할 필요가 없습니다.
3) 모든 사람들이 기억하고 있기를 바랄 수 있습니다. (권장하지 않음)
나는 개인적으로 두 번째로 갈 것입니다. 그것이 바로 모델 데이터베이스입니다.
@ Surfer513에 추가
4) 정책 기반 관리 정책은 단순 복구 모델을 시행하거나 DB가 아닌 경우 알려줍니다
모델을 간단하게 설정하는 것이 좋지만 T-SQL 명령을 사용하고 다른 것으로 설정하는 것을 방해하지는 않습니다. 정책을 사용하여 복구 모델이 단순하지 않은지 평가하고 정책에서이를 변경하도록 선택할 수 있습니다.
이 MSSQLTip.com 기사는 전체 검사에 관한 것이지만 단순 검사를 쉽게 할 수 있습니다. 또한 데이터베이스에서 백업이 발생했는지 확인하기 위해 검사를 던질 수도 있습니다.
안전한 베팅은 DB를 전체 모드로 설정하는 중이지만 로그 증가 문제가 있습니다. 이제 몇 가지 옵션이 있습니다.
DBA이므로 복구에 도움이되는 모든 옵션을 사용해야합니다. 또한 비즈니스와의 SLA에 따라 다릅니다.
모든 말로, 나는 간단한 모드로 몇 개의 DB를 관리합니다. 이는 SLA에 명시된 고지 사항 때문입니다. 이 회사는 로그 파일에 드라이브를 사용하지 않기로 결정했습니다 (물에 말을 타지 만 마실 수는 없습니다). 비즈니스는 백업, 복원 및 DR을 관리합니다. DR이 있었으며 손실 된 돈은 추가 디스크 공간에 필요한 것보다 컸습니다.