테이블 정의 변경, 새 개체, 패키지 변경 등 데이터베이스에 대한 변경 내용을 추적하기 위해 다른 사람들이 어떤 방법을 사용하고 있는지 알고 싶습니다. 외부 버전 제어 시스템과 함께 플랫 파일을 사용하십니까? 방아쇠? 다른 소프트웨어?
테이블 정의 변경, 새 개체, 패키지 변경 등 데이터베이스에 대한 변경 내용을 추적하기 위해 다른 사람들이 어떤 방법을 사용하고 있는지 알고 싶습니다. 외부 버전 제어 시스템과 함께 플랫 파일을 사용하십니까? 방아쇠? 다른 소프트웨어?
답변:
내가 작업 한 사이트에서 프로덕션 인스턴스에 필요한 변경 사항은 SQL * Plus에서 실행될 변경 스크립트로 스크립팅해야합니다. 또한 모든 스키마 개체를 처음부터 다시 작성하는 데 필요한 스크립트는 최신 상태로 유지해야합니다. 이 모든 스크립트는 변경 제어로 체크인되어 거기서 변경됩니다.
DDL 변경 사항을 감사하거나 DDL 트리거를 사용하여 변경 사항을 선택하거나 diff 소프트웨어를 사용하여 두 인스턴스를 비교할 수 있지만 이러한 방법은 무차별합니다. 종종 개발자는 정확히 변경해야하는 사항을 해결하기 전에 스키마에 대한 여러 가지 변경 (예 : 테스트 변경이 적거나 개념을 테스트하기위한 더미 테이블 작성 등)을 수행하고 실행 취소합니다.
이 주제에 대해 많이 생각하고 읽었습니다. 이것은 구성 제어 및 변경 관리 전략의 광범위한 주제입니다. CMMI에는이 주제에 대한 도메인이 있습니다. CMMI 3-5 인증을받은 회사에서도 데이터베이스를 버전 관리하지 않는 경우가 있습니다.
이 질문은 다음의 제약 조건 을 염두에두고 대답해야합니다 .
답변 1
이 방법은 6이있는 경우 잘 작동합니다. 코드 인 DDL 문도 소스 제어에 넣고 유지합니다. 아무도 신중하게 고려하지 않고 테스트 및 프로덕션 서버를 변경하지 않습니다.
단점은 어떤 이유로 든 빠른 버그 수정, 기본 키 변경 등 프로덕션 또는 테스트 서버를 변경하는 경우입니다. 해당 변경 사항을 개발 서버에도 적용해야합니다. 실제로 개발 서버는 GROUND TRUTH입니다. 다른 방법은 아닙니다.
이것은 매우 개발자 중심의 접근 방식입니다. 그러나 새로운 모듈을 처음 개발할 때는 꽤 잘 작동합니다.
답변 2-1 과 6이 참인 경우 :
답변 1에 대한 비슷한 접근 방식은 개발 서버를 유지 관리하는 것입니다. 모두가 그것을 사용합니다. 시간이 업데이트 될 때보 다. 데이터베이스 비교 도구를 사용합니다. 이것을 scripts로 가져 와서 소스 제어하에 두십시오.
- Red Gate Schema Compare supports Oracle
- Embercadero has similar tool
- https://github.com/carbonfive/db-migration
- http://www.sumsoftsolutions.com/svco/ (I have not used this product but I believe it belongs to this category.)
- Rails Active Migration (http://www.oracle.com/technetwork/articles/kern-rails-migrations-100756.html)
답변 1과 답변 2의 차이점은 답변 1에서 전체 데이터베이스에 대한 DDL 문을 수집하여 저장한다는 것입니다. 답변 2에서는 모든 버전의 변경 사항을 저장해야합니다.
열을 테이블에 넣고 나중에 제거하기로 결정하십시오. 스크립트는 answer2에 이것을 표시하고 answer1에는 마지막 버전 만 표시됩니다. 차이점을 보려면 V2와 V1을 비교해야합니다. 개인적으로 Start와 V3, V1 및 V3을 쉽게 비교할 수 있기 때문에 대답 1이 더 좋습니다. answer2에서 모든 변경 사항을 찾아야합니다. 또한 답변 2에서 소스 제어의 스크립트는 빅뱅, 복잡한 스크립트 인 경향이 있습니다. 정보를 찾기가 어렵습니다.
답 3 3이 참인 경우. 이 상황에서는 제한 조건 6이 없습니다. 즉, 개발, 테스트, 제품 서버가 없습니다. 프로덕션 서버 만 DDL 트리거를 사용하여 수행 된 변경 사항을 기록 할 수 있습니다. 이것은 주로 사람들이 DDL 보조금을 남용하지 못하게하는 데 사용됩니다. 문제가 발생하면 책임을 져야합니다. 이것이 작동하려면 모든 사람이 자신의 사용자 계정에 연결해야하고 응용 프로그램 계정에 DDL 권한이 없어야합니다. 모든 개발자는 응용 프로그램 계정을 알고 있으므로 사용할 수 있기 때문입니다.
답변 4 3과 5가있는 경우이 상황에서는 제약 조건 6이 없습니다. 즉, 개발, 테스트, 제품 서버가 없습니다. 프로덕션 서버 만 변경 사항을 저장하는 트리거 대신. 외부 도구를 사용하여 변경 사항을 찾고 소스 컨트롤에 DDL 스크립트를 저장합니다.
이러한 도구에 변경을 수행 한 사람을 기록 할 수있는 기능이 있으면 유용합니다. 이 솔루션에서는 간격으로 수행되는 추가 DDL을 느슨하게합니다.
11g 데이터베이스에 Schema Version Control 을 사용 했지만 11.2의 소프트웨어에 일부 문제가있었습니다. 우리가 여전히 겪고있는 문제가 아니라면 훌륭한 제품이 될 것입니다.
예전에는 SQL Developer Data Modeler로 대체 된 Oracle SQL Designer를 사용했습니다. http://www.oracle.com/technetwork/developer-tools/datamodeler/overview/index.html
아주 좋았어요. 열에 DOMAIN을 설정하고 공통 열 (mtime, ctime 등)을 작성하는 데 많은 시간을 절약 할 수 있습니다.
우리 는 SVN에서 oracle DDL 스키마의 자동 저장을 위해 oracle-ddl2svn 도구 세트 (저는 필자가 작성한 도구)를 사용합니다.
나는 그것을 사용한 적이 없지만 http://blog.gitora.com/ 은 또 다른 옵션입니다.