우리는 최신 데이터로 개발하기 위해 야간에 프로덕션 서버 데이터베이스에서 테스트 서버 데이터베이스를 업데이트하려고합니다. 그러나 우리는 개발 환경에서 현재 작업중인 fn, sp 등이 백업 프로세스에 의해 덮어 쓰이지 않도록 보장하고자합니다. 우리가 생각한 것은 백업 프로세스가 완료된 후에 우리 개발자와 포스트 백 프로그램이 선택한 오브젝트를 다시 저장하는 사전 백업 프로그램을 가지고있는 것입니다.SQL Server 2008 자동 백업
다른 개발자가 이와 같은 상황에서 어떤 작업을했는지 궁금합니다. 매일 우리가 자동으로 실행할 수 있고 우리가 덮어 쓰지 않는 객체를 설정할 수있게 해주는 기존 도구가 있습니까 (sysadmin이 매일 실행하지 않아도 됨).
우리 데이터베이스의 모든 객체는 코드, 테이블, 뷰, 트리거, 스토어드 프로 시저 등 모든 코드에서 유지 관리됩니다. 데이터베이스에서 해당 객체를 찾으려면 실행 가능한 코드의 DDL이어야합니다. 실제 스키마 변경 사항은 버전이 지정됩니다. 따라서 스키마 버전이 "n"이고 이것이 현재 버전이 아닌 경우 (업데이트 코드에 따라) 데이터베이스에 필요한 변경 사항을 적용하는 테이블이 있습니다.
우리는 트리거와 뷰를 분리하려고 노력합니다. 우리는 현재 스키마 버전에 유효한 코드를 삭제하고 다시 작성하여 SP 및 FN과 함께 많은 작업을 수행하지 않아도됩니다. 따라서 객체간에 종속성이있는 경우 드롭과 작성 모두에서 순서 지정 문제가 있지만 테이블이 아닌 것을 삭제하고 다시 만드는 것은 "안전"해야합니다. 이것에 대한 좋은 점은 일반적으로 새로운 스키마를 현재 스키마로 가져올 수 있으며 스키마의 인스턴스가 일관적임을 확신 할 수 있다는 것입니다.
현재 정의에 따라 모든 데이터베이스 개체를 다시 작성하기위한 코드가 포함 된 스키마 업데이트 코드를 실행하면 문제가 실질적으로 사라집니다. 백업, 복원, 스키마 실행 maint 논리. 이것은 dev 서버에서 스키마 (테이블) 변경을 도입 할 수 있고 여전히 동일한 업데이트 로직을 유지할 수있는 또 다른 이점이 있습니다.
저는 이것이 완전히 일반적인 해결책이 아니라는 것을 알고 있습니다. 그리고 그것은 개발자 당 데이터베이스에서 더 잘 작동한다는 점에 유의할 가치가 있습니다. (저는 구식 프로그래머입니다. 그래서 모든 문제점을 코드 기반 솔루션 (- :)으로 보았습니다. 그러나 일반적인 접근 방식으로 생각하면 상당한 이점이 있습니다. 많은 문제를 해결할 일관된 메커니즘입니다.