데이터 마이그레이션 계획을위한 워크 플로우는 무엇입니까?


23

소프트웨어 개발이 끝났을 때 많은 시간을 보냈으며 "알겠습니다. 새로운 코드를 모두 얻었고 테이블을 변경하고 데이터를 마이그레이션해야합니다."와 같은 말을 들었습니다 .

그것은 일회성, 적중에서 가장 잘 추론되는 시나리오 일 때마다 보인다. 이것이 DBA로서 가장 약한 기술이라고 생각합니다.

데이터 마이그레이션접근, 관리 및 테스트하기 위한 몇 가지 패턴에 대해 알고 싶습니다 .

모범 사례 및 / 또는이 분야에서 더 나아질 수 있도록 학습 자료를 얻을 수있는 곳을 알려주세요.

답변:


14

내가 할 때마다 우리는 두 번 통과했습니다 ...

  1. 스냅 샷을 작성하고 다른 서버에서 작업하고이를 사용하여 마이그레이션을 위해 수행 할 작업을 결정하고이를 스크립팅하십시오.
  2. 스크립트가 준비되면 스냅 샵은 테스트 시스템에서 복원되며 필요한 시간 내에 실행되는지 또는 시간이 지날 때까지 조정 및 수정되는지 확인합니다.
  3. 테스트 시스템의 데이터에 문제가없는 것으로 이해 관계자에게 서명하도록합니다.

그런 다음 주말에 예정된 중단이 발생합니다.

  1. 금요일 밤, 데이터베이스를 사용하는 시스템이 다운되고 전체 콜드 백업이 수행되며 스크립트가 데이터로 마이그레이션 / 수정 / 무엇이든 실행됩니다.
  2. 시스템은 개인 주소로 다시 설정되거나 어떤 식 으로든 설정되어 승인 테스트를 위해 다른 사람에게만 공개되지 않습니다.
  3. 이해 관계자가 승인하면 시스템은 온라인 상태가되고 공개됩니다. 그렇지 않은 경우 금요일 밤에 작성된 백업에서 데이터베이스가 복원되고 프로세스를 다시 시작합니다.

일정에 따라 데이터베이스 사용자는 일반적으로 금요일 오후 6 시부 터 토요일 오전 10 시까 지 백업 및 마이그레이션 스크립트를 실행했습니다. 따라서 우리의 목표는 8 시간 (8 시간은 백업)이었습니다. d 테스트 및 수정이 이해 관계자에게 공개되기 전에 약간의 시간이 있습니다.

이해 관계자들은 미리 시간대를 미리 정해 놓았 기 때문에 주말은 테스트 시작을 위해 창가에서 열어야한다는 것을 알았습니다. 또한 모든 사람들이 사인 오프하지 않은 경우 일반적으로 일요일 오후에 창 끝이라고 들었습니다. 롤백을 시작해야합니다.

물론, 어떤 사람이 수락 테스트 중 하나라도 변경을해서 변경 한 경우, 모든 이해 관계자의 서명이 취소되었고 다시 테스트해야한다는 것을 의미했습니다. 한 번에 하나씩 적용하는 대신 문제를 찾아 수정 사항을 일괄 적으로 실행하도록 모든 시간을 제공하려고합니다.

운 좋게도, 다운 타임이 현저하지 않은 상황 중 하나만 내가 마이그레이션 한 시스템은 사용자 입력이 아닌 스크립트에서 공급되었으므로 두 개의 병렬 시스템을 사용하여 스왑 할 수있었습니다. 일이 끝났을 때 (내 보스가 전체 백업을 수행한다고 주장했을 때 한 번만 문제가 발생했습니다. 모든 것이 여전히 다른 IP에서 온라인 상태가 될 것이라는 것을 이해하지 못했습니다 ... 그래서 5 분 동안 중단 된 것은 무엇입니까? 나쁜 날은 5 시간의 정전이되었습니다.)


6

그것은 모두 데이터베이스를 지원하는 하드웨어의 힘과 시스템 가용성에 대한 합의에 비해 데이터의 양에 달려 있습니다. 다운 타임이 발생 했습니까? 아니면 모두 온라인으로해야합니까? 오래된 행을 최대한 지우면서 데이터 정리를 시작하십시오. 이것은 자체 프로젝트입니다. 데이터가 깨끗하고 귀중한 경우 사용자에게 가동 중지 시간을 결정하도록하십시오. 다운 타임을 사용할 수있는 경우 업데이트 된 콜렉션을 형성하기 위해 기존 데이터에 적용해야하는 알려진 변환 인 경우 상당히 간단합니다. 가동 중지 시간이 없거나 매우 적은 경우에는 챌린지가 시작됩니다. Oracle은 온라인 테이블 재정의 및 11g의 새로운 에디션 기반 재정의와 같은 몇 가지 방식으로이를 지원합니다. 온라인 테이블 재정의를 통해 테이블을 새로운 형태로 만들 수 있습니다. 응용 프로그램이 이전 형식의 테이블에서 실행되는 동안이 작업을 수행 할 수 있습니다. 모두 준비 되었으면 새로운 형식의 테이블로 전환 할 수 있습니다. 또한 새로운 애플리케이션 코드를 도입하는 동시에 새로운 애플리케이션을 구축하는 데 필요한 가동 중지 시간이 시작됩니다. 라이브 데이터를 마이그레이션하고 Oracle Golden Gate와 같은 도구를 사용하여 동기화 된 상태로 유지하기 전에 이전 기록 데이터를 준비 할 수 있습니다. 이러한 시나리오에서는 기존 데이터베이스의 역할을 담당하는 새 데이터베이스를 효과적으로 구축합니다. 테이블 변경이 필요없는 경우 에디션 기반 재정의가 더 적합합니다. 고려해야 할 많은 옵션이 있으며 항상 효과가 좋은 규칙을 제시하기가 어렵다고 생각합니다. 또한 새로운 애플리케이션 코드를 도입하는 동시에 새로운 애플리케이션을 구축하는 데 필요한 가동 중지 시간이 시작됩니다. 라이브 데이터를 마이그레이션하고 Oracle Golden Gate와 같은 도구를 사용하여 동기화 된 상태로 유지하기 전에 이전 기록 데이터를 준비 할 수 있습니다. 이러한 시나리오에서는 기존 데이터베이스의 역할을 담당하는 새 데이터베이스를 효과적으로 구축합니다. 테이블 변경이 필요없는 경우 에디션 기반 재정의가 더 적합합니다. 고려해야 할 많은 옵션이 있으며 항상 효과가 좋은 규칙을 제시하기가 어렵다고 생각합니다. 또한 새로운 애플리케이션 코드를 도입하는 동시에 새로운 애플리케이션을 구축하는 데 필요한 가동 중지 시간이 시작됩니다. 라이브 데이터를 마이그레이션하고 Oracle Golden Gate와 같은 도구를 사용하여 동기화 된 상태로 유지하기 전에 이전 기록 데이터를 준비 할 수 있습니다. 이러한 시나리오에서는 기존 데이터베이스의 역할을 담당하는 새 데이터베이스를 효과적으로 구축합니다. 테이블 변경이 필요없는 경우 에디션 기반 재정의가 더 적합합니다. 고려해야 할 많은 옵션이 있으며 항상 효과가 좋은 규칙을 제시하기가 어렵다고 생각합니다. 라이브 데이터를 마이그레이션하고 Oracle Golden Gate와 같은 도구를 사용하여 동기화 된 상태로 유지하기 전에 이전 기록 데이터를 준비 할 수 있습니다. 이러한 시나리오에서는 기존 데이터베이스의 역할을 담당하는 새 데이터베이스를 효과적으로 구축합니다. 테이블 변경이 필요없는 경우 에디션 기반 재정의가 더 적합합니다. 고려해야 할 많은 옵션이 있으며 항상 효과가 좋은 규칙을 제시하기가 어렵다고 생각합니다. 라이브 데이터를 마이그레이션하고 Oracle Golden Gate와 같은 도구를 사용하여 동기화 된 상태로 유지하기 전에 이전 기록 데이터를 준비 할 수 있습니다. 이러한 시나리오에서는 기존 데이터베이스의 역할을 담당하는 새 데이터베이스를 효과적으로 구축합니다. 테이블 변경이 필요없는 경우 에디션 기반 재정의가 더 적합합니다. 고려해야 할 많은 옵션이 있으며 항상 효과가 좋은 규칙을 제시하기가 어렵다고 생각합니다.

흥미로운 주제입니다, 로널드


5

지금까지 좋은 답변입니다. 고려할 점을 몇 가지 더 추가하겠습니다.

먼저 간단한 SQL DML을 사용하여 마이그레이션을 수행 할 수있는 경우 SQL 엔진을 사용하여 모든 행이 성공적으로 처리되도록 할 수 있습니다. 하지만 일부 마이그레이션이 좀 더 복잡한 마이그레이션에 참여했습니다. 데이터가 새로운 구조로 이동함에 따라 실제 데이터 변환이있었습니다. 이 경우 다음 항목을 처리 할 수있는 프로세스가 있어야합니다.

  • 처리 된 레코드 대 레코드의 수를 계산합니다.
  • 변환하는 동안 오류를 감지하고 수정을 식별 한 후 변환이 계속되고 "잘못된"레코드의 재 처리를 허용하는 방식으로 처리하십시오.
  • 레코드 수에는 "잘못된"레코드가 포함되어야합니다. 즉, 레코드-인 = 레코드-아웃-굿 + 나쁜 레코드
  • 변환에서 레코드 수를 변경하는 경우 (예를 들어 하나의 입력 레코드가 둘 이상의 출력 레코드가 됨) 결과 출력 레코드 수를 예측 한 다음 해당 수에 대해 결과를 테스트 할 수 있습니다.

내가 추가해야 할 또 다른 요점은 계획대로 진행되지 않을 때 수행 할 작업에 대한 계획을 세우는 것이 중요하다는 것입니다. 이것은 실제로 전체 배포의 기능이지만 언급 할 가치가 있다고 생각할 정도로 자주 광택이 나는 것처럼 보입니다.


4

그것을하는 방법의 개관

시작하기

  • test / UAT / "working DB"에 "after"데이터베이스가 있습니다
  • 프로덕션에 "이전"데이터베이스가 있습니다. 따라서 어딘가 = "reference DB"라는 프로덕션 사본을 생성하는 데 사용하십시오. 또 다른 "스크립트 테스트 DB"
  • 또한 ALTER 등을 포함한 많은 개발 스크립트가 있기를 바랍니다. 그렇다면 개발 스크립트가 적용된 다른 프로덕션 사본을 깨끗하고 순서대로 적용하는 것이 좋습니다 = "change DB"

다음으로 downoad Red Gate 비교 도구 또는 Embarcadero SQL Change Manager와 같은 도구 입니다. 그것 없이는 쉽게 마이그레이션 할 수 없습니다. 비용은 절약되는 시간만큼 간단합니다. 그리고 가장 중요한 것은 생성 된 스크립트가 단일 트랜잭션에서 변경을 수행한다는 것입니다.

지금,

  • "참조"와 "변경"을 비교하는 도구를 사용하여 변경 및 롤백 스크립트 생성
  • "스크립트 테스트"에 변경 스크립트를 적용하고 "작업 DB"와 다시 비교
  • "스크립트 테스트"에 롤백 스크립트를 적용하고 "와 다시 비교하고"작업 DB "와 다시 비교

이제 안전하고 테스트 된 변경 및 롤백 스크립트가 적용됩니다.

전에 그리고 물론 백업 데이터베이스 어떤 변화가 통계적으로 똥은 항상 결국 일이 때문이다.

Red Gate 도구는 소스 제어 하의 폴더와 비교할 수도 있습니다. 그런 다음 소스 컨트롤의 ALTER 등을 실제 변경 스크립트와 별도로 캡처합니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.