데이터 마이그레이션에는 세심한 준비가 필요합니다. 데이터베이스 구조의 버전 마이그레이션: 기본 접근 방식 버전 기록 저장

현대 기업은 정보 시스템을 마이그레이션해야 하는 경우가 많습니다. 하지만 이 과정에는 장애물이 많기 때문에 신중한 준비가 선행되어야 합니다.

오래된 플랫폼의 운영과 관련된 위험을 줄이고, 정보 시스템을 국제 표준으로 가져오고, 비즈니스 프로세스의 효율성을 높이는 등 새로운 정보 시스템(IS)으로의 전환을 시작하는 데는 여러 가지 이유가 있을 수 있습니다. 그러나 회사가 직면한 과제가 무엇이든, 한 IP에서 다른 IP로의 전환은 신중하게 계획되고 준비되어야 합니다.

마이그레이션 문제

ERP, 청구, 처리 또는 코어 뱅킹과 같은 거래 시스템을 마이그레이션할 때 새로운 시스템으로의 전환은 매우 문제가 됩니다. 사실 IT 전문가는 대용량 데이터의 정확한 마이그레이션을 보장하고 결과 조정 및 분석을 위해 기존 시스템과 새 시스템의 병렬 운영을 유지해야 합니다.

예를 들어, 저는 거래 시스템이 더 이상 지원되지 않는 Informix 플랫폼에서 Oracle 플랫폼으로 이전되는 가장 큰 은행 중 한 곳에서 프로젝트 경험을 갖고 있습니다. 동시에, 비즈니스 프로세스에 대한 철저한 분석을 수행하고, 기존 시스템에서 새 시스템으로 데이터를 반복적으로 전송하고, 기간을 고려하여 새 시스템과 기존 시스템의 결과의 일관성을 확인해야 했습니다. 프로세스 규정. 그래서 마이그레이션 기간이 14개월이었습니다. 때로는 두 시스템의 병렬 작업이 더 오랜 시간 동안 계속될 수 있지만 몇 달로 제한되는 경우에도 새로운 IS의 작동을 보장하려면 두 시스템에서 동시에 작업을 수행하는 데 추가 컴퓨팅 성능과 기업 직원의 상당한 시간을 할당해야 합니다. .

부서 시스템에서 전사 수준으로

IP 업데이트는 세계화 및 중앙화 프레임워크 내에서 자주 발생합니다. 이를 통해 소프트웨어 시스템 지원 및 업데이트 비용을 크게 줄일 수 있습니다. 실제로 모든 직원에게 서비스를 제공하는 단일 플랫폼을 유지하는 것이 각 부서별로 별도의 도구를 유지하는 것보다 훨씬 쉽습니다. 예를 들어, 재고 회계 시스템을 성공적으로 마이그레이션하면 대규모 조직의 수천 개의 부서를 단일 플랫폼으로 이전하고 IT 비용을 크게 절감할 수 있습니다. 그러나 이 경우 준비의 대부분은 다양한 형식과 표현의 데이터 조정, 새로운 규정 개발 및 직원 상호 작용의 새로운 모델 구축에 달려 있다는 점을 기억해야 합니다.

또 다른 중요한 측면은 다른 기업 정보 시스템, 특히 자체 작성 및 특정 시스템과의 통합 인터페이스입니다. 이와 관련된 문제는 첫 번째 단계에서는 그다지 눈에 띄지 않을 수 있지만 다양한 부서와 전체 시스템 간의 상호 작용을 구축할 때 식별됩니다. 그리고 이전 시스템의 경우 이러한 인터페이스가 이미 프로그래밍 방식으로 또는 조직적으로 구현된 경우 새 시스템의 경우 새로 개발해야 할 수도 있습니다.

식사 중에 식욕이 생기는 것처럼 시스템 기능 확장에 대한 생각은 프로젝트 구현 중에 이미 나타날 수 있다는 점을 기억해야 합니다. 이는 일련의 추가 작업이 모두 필요함을 의미합니다.

행동 계획

시스템 마이그레이션에 대한 프로젝트 활동 경험에 따르면 이러한 프로젝트에는 신중한 준비가 필요하며 개별 계획이 수반되어야 합니다. 그러나 마이그레이션되는 시스템 유형, 소프트웨어, 데이터베이스 볼륨 등에 관계없이 일반적인 구성표는 거의 동일해 보입니다.

첫 번째 단계에서는 세부적인 감사를 수행하여 새 시스템의 작동 모드에 대한 모든 요구 사항을 파악하고 모든 주요 사용자를 인터뷰해야 합니다. 우리가 말하는 데이터의 양과 부하의 종류를 이해하는 것이 중요합니다. 그래야만 전문가가 올바른 마이그레이션 전략을 제안할 수 있습니다.

절차 자체도 신중하게 고려해야 하며 마이그레이션 중 시스템에 대한 사용자 액세스 규칙, 오류 발생 시 이전 상태로 롤백하는 절차, 이러한 프로세스에 관련된 다양한 전문가의 상호 작용과 같은 중요한 요소를 포함해야 합니다. .

고객과 합의한 후 일반적으로 여러 단계, 즉 데이터 복사, 검증, 두 시스템의 병렬 작동 및 새 플랫폼으로의 완전한 전환을 포함하는 세부 계획이 작성됩니다. 제 생각에는 전문적으로 구성된 시스템 마이그레이션에서 가장 중요한 것은 사용자가 스트레스 없이 점차적으로 새로운 자동화 시스템에서 작업을 시작할 수 있는 프로세스의 원활함입니다.

그러나 신중하게 준비하더라도 사용자를 "새로운 레일"로 이동할 때 인건비를 과소평가하는 일이 항상 방지되는 것은 아닙니다. 이 프로세스에는 회사 직원 교육과 새로운 시스템에 적응하는 동안의 지원이 모두 포함됩니다.

InTech의 레이프 폴센(Leif Poulsen)

생산을 자동화하고 생산 프로세스에 대한 정보를 수집하는 시스템은 상대적으로 수명이 짧습니다. 공정 장비의 수명이 다하기 전에 업그레이드하거나 교체해야 하는 경우가 많습니다. 많은 기업에서는 생산을 중단하지 않고 자동화 시스템을 교체하거나 업그레이드하는 것을 관리하는 것이 정말 어려운 일입니다. 따라서 현대화나 교체에 대한 객관적인 필요성은 어떤 일이 발생할 때까지 무시됩니다. 이 문서에서는 신중한 계획과 구성을 통해 이 작업을 성공적으로 수행할 수 있는 방법에 대해 설명합니다.

산업 자동화 시스템과 산업 IT 시스템을 현대화하고 교체해야 하는 두 가지 주요 요인은 이러한 시스템의 기술적 저하와 이러한 시스템이 지원하는 비즈니스 프로세스 요구 사항의 변화입니다.

기업이 운영 체제, 데이터베이스 및 응용 프로그램 소프트웨어를 현대화해야 할 필요성을 무시하면 시간이 지남에 따라 기술 시스템의 신뢰성이 저하됩니다. 이에 따라 장비 고장으로 인한 운영 위험도 증가합니다.

신중한 계획을 통해 운영 위험을 허용 가능한 수준으로 유지하는 동시에 투자를 보호하고 수명주기 비용을 최소화할 수 있습니다. 일반적인 자동화 또는 IT 시스템의 경우 투자 금액의 20~40%만이 시스템 구매에 사용됩니다. 나머지 60~80%는 고가용성을 유지하고 주기적으로 변화하는 요구 사항에 적응하는 데 사용됩니다.

기술적 저하를 방지하는 데 필요한 활동을 평가하는 것 외에도 새로운 과제와 잠재적인 비즈니스 기회를 고려해야 합니다. 비즈니스 환경은 끊임없이 변화하고 있으며 기존 기술을 개선하거나 새로운 기술을 도입할 수 있는 모든 기회를 항상 고려해야 합니다. 고비용 자동화 시스템의 마이그레이션을 주도할 수 있는 일반적인 비즈니스 기회는 시장 출시 속도, 경쟁력, 성장, 품질 및 규정 준수입니다.

장기 마이그레이션 계획

장기적인 시스템 마이그레이션 계획을 개발하면 기업은 시스템 운영 위험을 허용 가능한 수준으로 유지할 수 있습니다. 또한 위험 관리와 비즈니스 목표의 시기적절한 지원을 보장합니다. 마이그레이션 계획에서는 "최고의 제조 방법", 기술 기능, 불가피한 생산 중단 시간 등의 제한 사항을 고려해야 합니다.

일반적으로 장기 계획에 대한 접근 방식은 그림 1에 나와 있습니다. 회사가 5년 후에 원하는 위치, 거기에 도달하기 위해 어떤 조치를 취해야 하는지, 거기에 도달하는 데 필요한 리소스를 사용할 수 있는지 여부를 결정하기 위해 마이그레이션 계획이 개발됩니다. 이 접근 방식은 산업 기업을 위한 시스템 아키텍처 개발에 널리 사용되는 TOGAF 표준에 설명된 아키텍처 설계 원칙을 기반으로 합니다.

그림 1. 장기 마이그레이션 계획 수립에 대한 일반적인 접근 방식.

기존 아키텍처와 대상, 원하는 아키텍처를 구별할 필요가 있습니다. 이들 사이의 차이는 회사의 현재 위치와 미래에 차지하고 싶은 위치의 차이를 반영합니다. 마이그레이션 계획은 여러 전환 단계를 통해 기존 아키텍처에서 대상 아키텍처까지의 경로를 차트로 표시합니다.

각 아키텍처는 그림 1에 표시된 것처럼 비즈니스와 기술 간의 격차를 해소하는 일련의 "계층"으로 설명할 수 있습니다. 1. 다음 "레이어"에 주의를 기울여야 합니다.

  • 사업 목표이는 전반적인 전략 계획 노력의 일부입니다. 이를 통해 프로세스의 올바른 방향을 선택할 수 있습니다.
  • 비즈니스 모델생산 및 비즈니스 프로세스를 이해하는 맥락을 제공합니다. 일반적으로 여기에는 자재 흐름 및 프로세스에 대한 높은 수준의 설명이 포함됩니다.
  • 설명 생산 및 비즈니스 프로세스기술의 성공적인 적용과 비즈니스 관점에서 그 가치를 올바르게 평가하는 데 중요합니다.
  • 정보, 데이터 및 문서프로세스와 애플리케이션을 연결하는 데 중요합니다. 애플리케이션 간 정보 흐름의 상호 운용성과 관리가 특히 중요합니다.
  • 설명 애플리케이션높은 수준의 요구 사항을 공식화하고 인터페이스를 정의할 수 있습니다.
  • 정의 인프라, 컴퓨팅 및 네트워크요구 사항(하드웨어, 내결함성, 성능).
  • 제공 서비스효과적인 운영 관리 및 의사 결정 지원을 보장하기 위한 요구 사항을 정의합니다.

마이그레이션 계획 개발

전체 조직 또는 단일 프로덕션 사이트에 대한 마이그레이션 계획을 개발하는 것은 많은 사람이 참여하는 매우 복잡한 작업일 수 있습니다. 아래 설명과 같이 개발 프로세스를 여러 단계로 나누는 것이 좋습니다.

2부

1단계: 동원

기본 목표:

  • 업무와 목표에 대한 공통된 이해를 얻습니다.
  • 프로젝트가 계획된 조직을 동원한다
  • 프로젝트 단계의 이정표와 결과를 설명하여 계획을 자세히 설명합니다.
  • 필요한/사용 가능한 모든 정보를 수집합니다.
  • 개념, 실습 및 이론에 대한 적절한 이해 제공
  • 예정된 회의
  • 프로젝트 시작을 위한 워크숍

결과:

  • 자세한 상담 계획
  • 공동의 목표
  • 프로세스 개요

2단계: 분석

분석 단계의 목표는 다음과 같습니다.

  • 다음을 위해 비즈니스 및 생산 프로세스를 분석합니다.

IT 및 자동화 시스템을 서비스하는 인력의 준비 상태를 평가합니다.

미래 아키텍처에 대한 데이터 및 기능 요구 사항 이해

목표를 설정하고 비즈니스 사례를 구현하기 위해 미래 아키텍처의 주요 이점을 식별합니다.

  • 기존 아키텍처 분석

자동화 시스템, 데이터 수집, 생산 관리 시스템과 관련된 기존 생산 프로세스 결정

기존 비즈니스 프로세스 및 생산 자동화 시스템과의 연결 식별

기존 애플리케이션, 데이터, 논리적 및 물리적 인프라, 기술 지원 서비스 식별

이 단계에서는 다음 활동이 수행됩니다.

  • 다양한 프로세스에 대한 세미나 및 토론
  • 상황에 맞는 정보를 얻기 위한 사이트 방문
  • 기존 시스템에 대한 세미나 및 토론
  • 성숙도 수준과 규제 요구 사항 준수 여부를 결정하기 위한 서비스 평가

결과:

  • 기존 인프라 식별
  • 분석 문서
  • 새로운 아키텍처의 과제와 기회에 대한 아이디어 목록 새로운 아키텍처의 과제와 기회에 대한 아이디어 목록

3단계: 목표

이 단계의 목적은 분석 단계에서 공식화된 요구 사항을 식별하고 설명하는 것입니다.

솔루션 또는 대상 아키텍처는 다음을 설명합니다.

  • 미래의 비즈니스 프로세스 및 기능
  • 기능, 사용자, 정보 및 인터페이스를 포함한 대상 애플리케이션 유형
  • 인프라 요구 사항 및 개정된 지원 표준

이 단계에서는 다음 활동이 수행됩니다.

  • 프로세스 개선에 관한 세미나 및 토론
  • 아키텍처 개선에 관한 워크숍 및 토론

결과:

  • 미래건축(발표)
  • 애플리케이션 유형에 대한 간략한 설명

4단계: 정당화

정당화 단계의 목적은 프로젝트의 비용 및 이점에 대한 대략적인 추정을 기반으로 초기 비즈니스 사례를 제공하는 것입니다.

기존 상황과 원하는 상황 사이의 격차는 일반적으로 여러 아이디어의 출현으로 이어집니다. 아이디어의 정당화를 통해 "필요한 것"과 "바람직한 것"을 구별할 수 있으며, 그 후 최고 경영진에게 아이디어를 제시하고 개발할 수 있습니다.

이 단계에서는 다음 활동이 수행됩니다.

  • 비용 및 이점의 대략적인 추정
  • 프레젠테이션의 첫 번째 버전

결과:

  • 공동의 목표
  • 사업 아이디어의 우선 순위
  • 필요한 자원 평가

5단계: 계획

이 단계의 목적은 우선 순위, 리소스 및 종속성을 기반으로 프로젝트를 계획하는 것입니다.

  • 통합 프로젝트 단계의 구현 순서 계획
  • 다음 단계에 필요한 자원과 역량을 제공합니다.
  • 프로젝트 관리 활동의 시작
  • 컨설팅 완료 및 모든 단계의 결과를 고객에게 전달

이 단계에서는 다음 활동이 수행됩니다.

  • 구현 계획 개발
  • 투자 계획 개발
  • 위험 평가

결과:

  • 실행 계획
  • 프로젝트에 관련된 인력의 작업량 평가
  • 프로젝트 위험 평가
  • 투자 계획(1차 근사치)
  • 프로젝트 프레젠테이션의 최종 버전

사례 연구

다음 예에서는 설명된 접근 방식을 실제 조건에 적용하는 방법을 보여줍니다. 기밀 유지 조건을 준수하기 위해 설명에는 익명성이 유지됩니다. 우리는 의약품의 활성 성분을 생산하는 상당히 큰 기업에 대해 이야기하고 있습니다. 생산 시설은 20여년 전에 가동되었으며 그 이후 일부 현대화가 진행되었지만 다수의 노후된 시스템을 교체해야 합니다. 빌딩 자동화 시스템과 DCS는 유지 관리가 어려운 오래된 기술을 기반으로 하기 때문에 가장 먼저 사용됩니다. 또한 생산은 일부 제품의 단종 및 다른 제품의 출시를 포함하여 새로운 비즈니스 요구에 적응해야 합니다. 일반적으로 기술 요구 사항과 비즈니스 요구 사항을 모두 포괄하는 마이그레이션 계획을 수립해야 합니다.

먼저, 현재 기업 전체에서 사용되는 장비의 마스터 목록을 만들어야 합니다. 이 정보는 다양한 문서(및 직원의 기억)에 "숨겨지는" 경우가 많습니다. 마이그레이션 계획의 기초가 되도록 추출하고 시각화해야 합니다. 이를 위해 우리는 일반적으로 각 제조 단위의 주요 장비와 원자재 이동을 보여주는 프로세스 모듈 다이어그램을 만듭니다. 하드웨어 "상단"의 별도 레이어로서 어떤 시스템이 어떤 하드웨어를 지원하는지 보여줍니다.

예가 그림에 나와 있습니다. 2. 설치된 시스템에 대한 데이터는 시스템 저장소(또는 단순히 Excel 파일)에도 포함되어 있으며 추가 분석 및 계획에 사용될 수 있습니다.

그림 2. 자동화 "계층"을 통해 기존 시스템을 평가할 수 있습니다.

마이그레이션 계획을 논의하기 전에 생산 변경에 대한 주요 비즈니스 이유를 식별해야 합니다. 이 경우 경영진은 다음과 같은 동기를 식별했습니다.

1. 규제 요구 사항을 일관되고 오류 없이 준수합니다.

2. 시장 진입에 필요한 최소 시간, 유연성

3. 성공, 경쟁력, 운영 우수성

4. 타협하지 않는 품질

5. 생산량 증가

이러한 목표는 보다 구체적인 작업으로 변환되어야 하며, 그 구현은 정량화될 수 있습니다.

다음으로, 기존 시스템이 현재와 미래의 비즈니스 프로세스를 얼마나 잘 지원하는지 알아내야 합니다. 이를 위해 우리는 표준 참조 모델(ANSI/ISA-95 표준 시리즈 기반)을 사용합니다. 여기에는 실제 구현의 약점과 효과적인 비즈니스를 위한 변화의 필요성을 확인할 수 있을 정도로 상세한 19개의 상위 수준 비즈니스 프로세스가 포함되어 있습니다.

또한 향후 비즈니스 프로세스를 지원하기 위해 기존 시스템의 기술적 역량도 평가해야 합니다. 이는 위에서 설명한 시스템 저장소의 정보를 사용하여 체계적으로 수행됩니다. 정보가 저장소에 있는 각 시스템(우리의 경우 약 70개 시스템)에 대해 다음 측면을 평가해야 합니다.

  • 장비 상태(고장 이력, 평균 고장 간 시간, 장비 수명, 예비 부품 가용성)
  • 소프트웨어 상태(공급업체 지원, 문서 가용성, 필요한 역량을 갖춘 인력)
  • 시스템 복구 기능(이중화, 수리 전 평균 서비스 수명)
  • 비즈니스 영향 평가(정보 제공, 데이터 오류, 비가용성)
  • 지표(시스템 신뢰성, 시스템의 중요성 등)

기술 평가에서는 다음과 같은 여러 시스템을 현대화하고 교체해야 할 필요성이 확인되었습니다.

  • 프로세스 제어 시스템은 기존의 구식 DCS와 다양한 PLC를 기반으로 하며, 그 중 일부는 이미 교체가 가능합니다.
  • 빌딩 자동화 시스템은 최신 플랫폼을 기반으로 하지만 새로운 요구 사항을 충족하려면 업그레이드도 필요합니다.
  • 다수의 보조 시스템에도 현대화 또는 교체가 필요합니다.
  • 모든 시스템에 서비스를 제공하는 인프라에는 오늘날의 보안 요구 사항을 충족하기 위해 더 나은 분할과 보호가 필요합니다.

3부

미래에 대한 비즈니스 목표를 분석한 결과, 기존 시스템 중 어느 것도 미래 요구 사항을 완벽하게 충족할 수 없다는 것이 분명해졌습니다. 이러한 이해는 신기술 도입과 생산 실행 시스템에 관한 많은 아이디어를 낳았습니다. 분석 결과, 지속적으로 구현된다면 회사가 미래의 기술 및 상업적 요구 사항을 충족하는 데 도움이 될 16개의 다양한 프로젝트가 제안되었습니다.

기술 작업의 내용과 각 프로젝트의 비용이 평가됩니다. 각 프로젝트에 대해 경영진이 논의할 수 있도록 짧은 한 페이지 요약이 준비됩니다. (그림 3 참조)

쌀. 3. 잠재적 마이그레이션 프로젝트에 대한 한 페이지 설명

우선순위 프로젝트를 선택하기 위해 각 프로젝트의 잠재적 결과를 평가합니다. 결과는 비즈니스 목표와 프로세스 제어 시스템의 신뢰성 측면에서 평가됩니다.

일반적으로 각 계획에 대한 전체 리소스 및 자금 요구 사항을 추정하려면 여러 구현 시나리오를 평가해야 합니다(그림 7). 고려해야 할 주요 제약 사항 중 하나는 생산 과정에서 시스템을 교체하거나 수정할 수 있는 기간입니다. 일반적으로 이러한 "창"은 주말에 발생하며 이는 심각한 병목 현상입니다.

쌀. 7. 마이그레이션 일정 통합 개요

시스템을 교체하고 설정하는 데는 항상 시간이 거의 없기 때문에 준비가 매우 철저해야 합니다. 모든 것이 상세하게 계획되어야 합니다. 계획의 중요한 측면은 구현된 시스템을 테스트하는 것입니다.

우리가 설명하는 경우 장기 마이그레이션 계획의 구현은 6가지 다른 흐름으로 수행되었습니다(그림 1 참조). 8.

쌀. 8. 6가지 다른 흐름으로 마이그레이션 프로젝트 구성

준비의 일부는 프로젝트 위험에 대한 철저한 평가 및 예방입니다. 그림에서. 그림 9는 마이그레이션 프로젝트와 관련된 일반적인 위험을 보여줍니다.

쌀. 9. 마이그레이션 프로젝트의 일반적인 위험 평가

비즈니스 지원 프로세스

이 문서에 설명된 수명 주기 관리 및 장기 마이그레이션 계획 접근 방식은 비즈니스 요구 사항에 따라 결정됩니다. 여기에는 현재 및 미래의 비즈니스 목표에 대한 평가는 물론 해당 목표를 가장 잘 지원하기 위해 기술 시스템을 유지 관리하거나 교체하는 방법에 대한 철저한 분석이 포함됩니다. 이 접근 방식은 예산 및 자격을 갖춘 인력의 가용성에 따라 순차적인 프로젝트 구현을 제공하는 TOGAF 원칙을 기반으로 합니다. 현재와 ​​미래의 시스템 아키텍처를 평가하는 것은 향후 마이그레이션 프로젝트를 결정하는 핵심 요소입니다. 마지막으로, 마이그레이션 프로젝트의 성공에 매우 중요한 주요 프로젝트 이해관계자의 적시 참여를 보장하는 조직 변경 관리 원칙을 준수해야 합니다. 이 접근법의 효과는 실제로 반복적으로 입증되었습니다.

레이프 폴스N) ( ), NNE Pharmaplan의 선도적인 자동화 및 IT 전문가입니다. 그는 프로세스 관리 분야의 석사 학위를 보유하고 있습니다. NNE Pharmaplan에서 Poulsen은 산업 자동화 및 IT 분야의 기술, 방법 및 역량 개발을 담당하며 수석 비즈니스 컨설턴트로 활동하고 있습니다.

최종 업데이트 날짜: 2015년 10월 31일

모델이 변경되면 상황이 발생하는 경우가 많습니다. 예를 들어, 우리는 여기에 새로운 속성을 도입하기로 결정했습니다. 그러나 동시에 일부 데이터가 포함된 기존 데이터베이스가 이미 있습니다. 그리고 손실 없이 데이터베이스를 업데이트하기 위해 ASP.NET MVC는 마이그레이션과 같은 메커니즘을 제공합니다. 예를 들어 간단한 사용자 모델이 있습니다.

공용 클래스 사용자( 공용 int Id( get; set; ) 공용 문자열 이름( get; set; ) )

따라서 데이터베이스 작업에 사용되는 데이터 컨텍스트가 있습니다.

사용자(get;set;))

그리고 이 모델을 사용하기 위한 모든 인프라(뷰, 컨트롤러)가 있고 데이터베이스에 이 모델의 여러 개체가 이미 있다고 가정해 보겠습니다. 그러나 어느 시점에서 우리는 애플리케이션 모델 기반을 변경하기로 결정했습니다. 예를 들어 User 모델에 또 다른 필드를 추가했습니다.

공용 클래스 User ( public int Id ( get; set; ) 공용 문자열 이름 ( get; set; ) public int Age ( get; set; ) )

또한 우리는 다음과 같은 모델을 하나 더 추가하기로 결정했습니다.

공용 클래스 회사( 공용 int Id( get; set; ) 공용 문자열 이름( get; set; ) )

따라서 데이터 컨텍스트는 이미 다음과 같이 변경되고 있습니다.

공용 클래스 UserContext: DbContext ( public UserContext() : base("DefaultConnection") ( ) 공용 DbSet 사용자( get; set; ) 공개 DbSet 회사 ( get; set; ) )

User 모델의 뷰에 Age 속성에 대한 추가 필드를 추가할 수 있고 새 모델에 대한 컨트롤러와 뷰를 만들 수 있지만 데이터베이스에 새 개체를 추가하려고 하면 오류가 발생합니다.

데이터 컨텍스트가 변경되었으므로 이제 이전 데이터베이스 스키마에서 새 데이터베이스 스키마로 마이그레이션해야 합니다. 먼저 Visual Studio 하단에서 패키지 관리자 콘솔 창을 찾아 그 안에 활성화-마이그레이션 명령을 입력하고 Enter 키를 누릅니다.

이 Visual Studio 명령을 실행하면 프로젝트에 마이그레이션 폴더가 생성됩니다. 여기서 파일을 찾을 수 있습니다. 구성.cs. 이 파일에는 구성 설정을 설정하는 동일한 이름의 Configuration 클래스 선언이 포함되어 있습니다.

네임스페이스 MigrationApp.Migrations(System 사용, System.Data.Entity 사용, System.Data.Entity.Migrations 사용, System.Linq 사용, 내부 봉인 클래스 구성: DbMigrationsConfiguration ( 공개 Configuration() ( AutomaticMigrationsEnabled = false; ContextKey = "MigrationApp.Models.UserContext"; ) protected 재정의 void Seed(MigrationApp.Models.UserContext context) ( ) ) )

Seed 메소드에서는 시드 데이터로 데이터베이스를 초기화할 수 있습니다. 이제 마이그레이션 자체를 생성해야 합니다. 패키지 관리자 콘솔에서 다음 명령을 입력합니다.

PM 추가 마이그레이션 "MigrateDB"

그러면 Visual Studio가 자동으로 마이그레이션 클래스를 생성합니다.

네임스페이스 MigrationApp.Migrations( System 사용; System.Data.Entity.Migrations 사용; 공개 부분 클래스 MigrateDB: DbMigration( 공개 재정의 void Up() ( CreateTable("dbo.Companies", c => new ( Id = c.Int( null 허용: false, ID: true), Name = c.String(), )).PrimaryKey(t => t.Id) AddColumn("dbo.Users", "Age", c => c.Int(nullable) : false)); ) 공개 재정의 void Down() ( DropColumn("dbo.Users", "Age"); DropTable("dbo.Companies"); ) ) )

Up 메서드에서는 CreateTable 메서드를 호출하여 "dbo.Companies" 테이블이 생성되고 해당 구성(열 생성, 키 설정)이 수행됩니다. 또한 기존 테이블에 새로운 Age 열도 추가됩니다. Down 메서드는 열과 테이블이 있는 경우 이를 제거합니다. 실제로 이러한 메소드는 데이터베이스와 해당 테이블의 구조를 변경하는 SQL의 ALTER 표현식과 동일합니다.

마지막으로 마이그레이션을 수행하기 위해 동일한 콘솔에 명령을 입력하여 이 클래스를 적용합니다.

PM 업데이트-데이터베이스

그런 다음 데이터베이스 구성을 살펴보면 수행된 마이그레이션에 따라 변경 사항이 적용되었음을 확인할 수 있습니다.

따라서 마이그레이션이 완료되었으며 이미 업데이트된 모델과 데이터 컨텍스트를 사용할 수 있습니다.

이 기사에서는 고객이 1C:Enterprise 8 구성에서 작업하도록 전환하는 것과 관련된 대규모 기업 프로젝트에서 데이터 마이그레이션을 수행한 경험을 체계화하고 싶습니다.

동시에 이 기사에서는 우선 마이그레이션 프로세스의 기술적 구성 요소에 중점을 둘 것입니다. 조직 구성 요소도 영향을 받지만 그 정도는 적습니다.

용어 및 정의

데이터 마이그레이션은 일반적으로 작업의 최종 시퀀스, 즉 소스 시스템(과거 시스템)에서 대상 시스템으로 데이터를 일회성으로 대량 이동하는 것을 목표로 하는 프로젝트로 이해됩니다. 동시에 소스 시스템에서 이 데이터의 활용이 중단됩니다.

데이터 마이그레이션은 데이터 통합과 구별되어야 합니다. 마이그레이션과 달리 통합은 IT 아키텍처의 영구적인 부분이며 다양한 시스템과 데이터 저장소 간의 데이터 흐름을 담당하며 프로젝트 활동이 아닌 프로세스입니다.

일반적인 마이그레이션 계획은 다음과 같습니다.

쌀. 1

역사적 시스템- 새로운 시스템을 구현할 때 전체 또는 부분적으로 교체될 예정인 고객 회사의 데이터베이스.

수신기 시스템- 대상 시스템, 임의 구성 "1C:Enterprise 8".

초기 데이터- 과거 시스템에서 사용자 정의 xls 파일 형식으로 다운로드된 데이터입니다. 이 경우 xls 파일에 업로드하는 기능이 "이전 세대"의 많은 회계 시스템에 존재하기 때문에 xls 형식이 가장 편리한 것 중 하나인 것 같습니다.

현대적인 대안으로 xml 파일 형식을 전송으로 간주하는 것이 가능합니다.

중간 데이터베이스를 사용하는 옵션도 있습니다.

변환, 전환- 소스 데이터를 로드할 데이터로 변환하는 프로세스입니다. 로드된 템플릿에 따라 데이터 변환이 발생합니다. 변환의 결과는 로드할 데이터입니다.

데이터 다운로드- 수신 시스템에 로드하기 위한 데이터입니다. 이 기사와 원본 데이터에서는 xls 형식을 고려합니다.

로드용 데이터 템플릿- 타겟 시스템에 로드될 데이터 테이블에 대한 설명입니다.

마이그레이션 단계

마이그레이션을 준비하고 수행하는 과정을 단계별로 살펴보겠습니다.

마이그레이션의 조직적 단계에는 다음 사항이 포함됩니다.

· 마이그레이션 전략 정의. 이 단계에서 계약자와 고객은 마이그레이션 작업을 수행하기 위한 기술에 동의합니다.

· 마이그레이션 실무 그룹 구성 결정. 작업 그룹에는 과거 시스템(고객 측)과 대상 시스템(계약자 측)의 운영에 대해 충분히 잘 알고 있는 계약자와 고객 모두의 전문가가 포함되어야 합니다.

· 예비 마이그레이션 계획. 마이그레이션 계획은 프로젝트가 진행됨에 따라 여러 번 조정됩니다.

· 과거 시스템에서 데이터를 다운로드하는 날짜 기간, 데이터 양. 마이그레이션에 대한 데이터 마감 기간, 테스트 날짜 및 최종 마이그레이션. 이 정보는 마이그레이션 계획에 기인할 수 있습니다.

· 마이그레이션할 데이터의 구성. 참고자료, 분류기준, 거래자료, 잔액, 매출액 등

· 마이그레이션 프로세스 도중과 마지막에 데이터의 품질, 정확성 및 무결성을 확인하는 문제;

· 장애 발생 시 이전 상태로 롤백되는 문제.

마이그레이션의 기술적 단계를 자세히 살펴보겠습니다.

쌀. 2

1.데이터 로딩 템플릿 준비

데이터 로딩 템플릿에는 로드할 데이터 테이블에 대한 기술적인 설명, 현재 템플릿에 대한 알고리즘 및 로딩 규칙이 포함되어 있습니다.

각 템플릿은 일반적으로 대상 시스템에 있는 하나 이상의 관련 테이블을 대상으로 합니다.

템플릿에는 다음과 같이 명시되어 있습니다.

· 다음을 포함하여 다운로드할 xls 데이터 파일의 모든 필드에 대한 설명:

o 필드 이름

o 해당 필드를 채워야 함을 나타내는 표시

o 필드 작성 예시

o 참고

· 로드할 데이터를 기준으로 대상 시스템 테이블을 로드하는 규칙에 대한 설명(관련 테이블이 여러 개인 경우 큐, 키 필드에 대한 검색 알고리즘 등)

· 로드를 위해 데이터 파일에서 "일대일"로 데이터를 전송하는 것 외에 다른 것이 제공되는 경우 대상 시스템 테이블의 필드를 직접 채우는 설명이 제공됩니다. 예를 들어 참조 필드와 관련이 있습니다.

이 단계의 작업 중에 계약자는 로드할 데이터 파일 로더도 준비해야 합니다. xls 파일로 작업할 때 이 작업은 특별히 어렵지 않습니다.

2.데이터 소스 식별

이 단계는 이전 단계 “1. 데이터 로딩 템플릿을 준비 중입니다."

이 단계에서 고객의 전문가는 어떤 시스템에서 어떤 데이터를 다운로드할 수 있는지 결정합니다. 또한 어떤 데이터가 무엇인지 결정해야 합니다. 아마도 필요할 수 있습니다.

일반적으로 대규모 마이그레이션 프로젝트에서는 전체 데이터 소스 목록을 식별하는 데 꽤 오랜 시간이 걸릴 수 있으며 후속 단계에서 작업이 계속되면서 발생합니다.

정보의 무결성을 더욱 보장하기 위해 일부 데이터를 인쇄된 소스에서 전송(디지털화)하거나 고객의 주요 직원의 말에 따라 테이블에 입력해야 하는 경우가 종종 있습니다.

그러나 이 단계에서는 필요한 데이터를 최대한 많이 식별하도록 노력해야 합니다.

3.소스데이터 업로드

과거 시스템에서 데이터를 다운로드하는 프로세스는 상당히 많은 시간이 걸릴 수 있습니다. 특히 시스템이 많고 시스템이 다르며 고객의 다양한 부서가 이를 담당하는 경우 더욱 그렇습니다. 테스트 및 최종 마이그레이션 중에 이 점을 고려해야 합니다.

가장 편리한 옵션은 xls 파일로 업로드하는 것 같습니다. 많은 구형 IT 시스템이 이 옵션을 지원합니다.

csv 형식, dbf, xml 형식 등으로 업로드하는 옵션도 있을 수 있습니다.

어떤 이유로든(예: 보안 문제) 고객이 이 단계에서 항상 전체 데이터 다운로드를 제공할 수는 없다는 점에 유의할 가치가 있습니다! 데이터 구조와 몇 가지 테스트 위치만 있으면 됩니다. 따라서 테스트 및 최종 로드 중에 소스 테이블에서 품질이 낮은 데이터가 감지되어 예기치 않은 오류가 발생하는 상황이 발생할 수 있습니다.

이 문제를 최소화하려면 과거 시스템의 테스트 다운로드 양을 미리 합의해야 합니다.

4.데이터 매핑

매핑(데이터 매핑) - 일반적으로 과거 시스템과 수신 시스템의 데이터를 비교하는 프로세스입니다. 즉, 원본 데이터와 로드할 데이터입니다.

매핑 단계는 가장 노동 집약적인 단계이며 마이그레이션 작업의 전체 작업 중 50% 이상을 차지할 수 있습니다.

이 단계에서는 전체 마이그레이션 프로젝트 실무 그룹이 완전히 참여합니다.

데이터 매핑 과정에서는 테이블 매핑과 필드 매핑의 하위 단계를 구분해야 합니다.

· 테이블 매핑 또는 템플릿 매핑 - 소스 데이터 테이블과 로드할 데이터 템플릿을 비교합니다. 매치는 1:1 또는 N:N이 될 수 있습니다. 이 작업의 결과로 테이블 매핑 레지스트리가 컴파일되고 유지 관리됩니다. 이 하위 단계는 필드 매핑의 다음 하위 단계와 매핑의 일반적인 상태를 모니터링하는 데 필요합니다.

1C 템플릿 그룹

1C 템플릿의 이름

파일 이름-

원천

소스 파일 생성 규칙

책임이 있는

상태

메모

NSI

견본_

명명법

노멘크

xls.xls

시스템 N에서 선택 설정
. txt로 저장
. xls로 열면 열은 텍스트입니다.
. 첫 번째 줄은 헤더입니다.
. 열 수 - 15
. txt 및 xls의 줄 수 확인
. 시트 이름은 항상 "Sheet1"입니다.

이바노프 I.I.

직장에서

· 필드 매핑 - 이미 정의된 테이블 매핑 내의 매핑 테이블 필드입니다. 이 작업의 결과는 필드 매핑 레지스트리입니다.

pp

Cl. 필드

필수의

1C 템플릿 필드 이름 "Template_Nomenclature"

설명

필드 이름 "Nomenclature.xls"

채우기 알고리즘

암호

디렉토리 요소 코드

암호

이름

이름

예

이 그룹

다음 값 중 하나를 포함합니다.
. 1 - 그룹용
. 0 - 요소의 경우

코드 길이=11자이고 마지막 4자가 있는 경우<>"0000"이면 이 요소는 "0"이고, 그렇지 않으면 그룹은 "1"입니다.

성명

디렉토리 요소 이름

이름

ThisGroup = 1이면 "", ElseIf ThisGroup = 0이면 Name입니다.

이 단계의 일부로 데이터 정규화에 대한 작업도 수행되어야 합니다.

5.변환 규칙 준비

이전 단계와 달리 이 단계는 기술적이며 계약자 개발자의 작업이 포함됩니다.

합의된 필드 매핑 레지스터를 기반으로 계약업체의 전문가는 데이터 변환 규칙을 개발합니다.

마이그레이션 준비 단계, 나아가 테스트 및 최종 마이그레이션 단계의 운영 작업을 위해서는 데이터 변환을 위한 규칙(스크립트)을 개발하기 위한 편리한 환경과 소스 데이터를 로드할 데이터로 변환하기 위한 환경이 있는 것이 중요합니다.

이 환경에 대한 요구 사항은 다음과 같습니다.

· 변환 규칙 개발의 편리성과 속도;

· 데이터 변환 속도. 입력 및 출력 파일의 길이는 수십만 줄이 될 수 있습니다!

· 여러 입력 파일을 동시에 작업하는 능력;

· 별도의 파일에 변환 규칙을 저장하는 기능.

마이그레이션 프로젝트를 위해 표준 1C 쿼리 콘솔 처리를 기반으로 전문 개발자 워크스테이션을 개발했습니다.

xls 파일에 대한 직접 쿼리를 허용하도록 쿼리 콘솔 처리가 개선되었습니다.

다음은 두 개의 소스 xls 파일을 결합하는 예입니다. 직원.xls


직원 코드

성

이름

성

생일

2423

이바노프

이반

이바노비치

17.11.1992

1523

페트로프

바질

알렉산드로비치

04.02.1991

4363

시도로프

키릴

니콜라예비치

01.05.1995

데니소프

데니스

데니소비치

01.01.1990

그리고 운영.xls페이지 포함:

상각

직원 코드

날짜

합집합

2423

01.02.2014

1523

02.02.2014

4363

03.02.2014

04.02.2014

100000

2423

05.02.2014

1523

06.02.2014

4363

07.02.2014

2356

08.02.2014

140000

2423

09.02.2014

1523

10.02.2014

4363

11.02.2014

23523

12.02.2014

80000

그리고 영수증:

직원 코드

날짜

합집합

01.05.2004

02.05.2004

03.05.2004

04.05.2004

2423생일

영수증 금액

상각된 금액

이바노프 이반 이바노비치

2423

17.11.1992

1341234

1010

페트로프 바실리 알렉산드로비치

1523

04.02.1991

245245

데니소프 데니스 데니소비치

01.01.1990

380000

320000

시도로프 키릴 니콜라예비치

4363

01.05.1995

613382

26336

총:

2579861

347842

이 예는 데이터 소스 변환의 가능한 모든 단계를 보여주기 위해 특별히 선택된 인공적인 것입니다.

여기서 변환 작업의 기술 순서는 다음과 같습니다.

1C 쿼리 언어에 비해 상당한 추가 기능을 제공하는 Access SQL 쿼리 언어를 사용하여 xls 파일에서 1C 환경으로 데이터를 추출하는 초기 쿼리가 생성됩니다. 동시에 이 단계에서는 이미 다양한 확인과 데이터 정규화가 가능합니다.

ADO 데이터 액세스 기술은 고속을 제공합니다.

쌀. 삼

2. 1C 언어 쿼리 - 필드 매핑 알고리즘을 구현하는 기본 쿼리입니다. 또한 1C 데이터베이스의 데이터로 다운로드한 데이터 강화, 재그룹화, 다른 소스 xls 파일에 대한 쿼리 결과 병합 등

3. 필요한 경우 1C 요청 결과를 사후 처리합니다. 1C 언어의 스크립트를 사용하여 구현되었습니다.

예를 들어 여기서는 금액 열에 "TOTAL" 줄을 추가하는 기능을 구현합니다.

4. 최종 데이터 세트를 xls 파일에 기록합니다.

일반적으로 출력은 대상 1C 데이터베이스에 로드하기 위한 최종 파일입니다.

이 도구를 사용하면 데이터 변환 규칙을 별도의 xml 파일에 저장할 수도 있습니다.

게다가 취업도 가능해요 V 배치 모드이는 이기종 마이그레이션 데이터의 양이 많을 때 특히 중요합니다.

이전 단계에서는 일반적으로 작업의 준비 부분이 종료됩니다. 모든 데이터 소스가 식별되고, 소스 데이터가 소스에서 다운로드되고, 다운로드 템플릿이 대상 데이터베이스에 준비되고, 데이터 매핑이 준비되고, 마지막으로 데이터 변환 스크립트가 개발됩니다. .

최종 마이그레이션 전에 반드시 몇 가지 테스트를 수행해야 한다는 점에 유의해야 합니다. 테스트 마이그레이션 중에 계약자는 고객과 함께 다음을 식별합니다.

변환 오류, 데이터 로딩 오류

대상 시스템에 로드된 데이터의 품질에 대한 사전 평가 수행

테스트 마이그레이션 결과를 바탕으로 최종 마이그레이션 계획을 수립/업데이트합니다.

7.데이터 조정

다운로드한 데이터의 품질은 테스트 마이그레이션 후와 최종 마이그레이션이 끝날 때 모두 확인해야 합니다. 조정 중에 다음 지표를 확인할 수 있습니다.

· 문서에 따른 잔액 총액의 일치;

· 양적 일치(예: OS 수);

· 선택한 개별 엔터티를 올바르게 작성합니다.

데이터 마이그레이션에 대한 특정 검사와 데이터 정규화 문제는 모든 마이그레이션 프로세스 전반에 걸쳐 해결되어야 합니다. 다음 단계에서 실수를 방지하려면 현재 단계에서 무엇을 해야 하는지 항상 자문해야 합니다.

예를 들어:

· 주요 필드별로 중복을 확인하세요. 이는 원본 데이터에 대해 수행될 수 있고 수행되어야 합니다.

· 필드 유형 강제;

· 참조 무결성;

· 수학적 불일치. 예를 들어 변환 중에 분할이 계획된 빈 숫자 필드를 확인합니다.

· 일반적으로 확인 필수 항목은 입력됩니다.

· 잘못된 문자를 교체합니다. 예를 들어, 키릴 문자 필드의 영어 문자("o", "a", "e" 등) 이는 특히 키 필드에 해당됩니다!

· 수신 시스템 유형에 맞는 문자열 필드의 값 확인(길이 제한)

최종 마이그레이션이 완료된 후 사전 결정된 마이그레이션 전략 및 마이그레이션 계획에 따라 과거 시스템의 추가 운영에 대한 결정이 내려집니다.

최종 데이터 조정 및 마이그레이션 성공 기록 직후 작업이 완료되는 경우가 많습니다. 새 시스템 사용자는 더 이상 두 시스템에 동시에 기록을 보관하지 않고 새 시스템으로 완전히 전환합니다. 동시에 기존 시스템에 대한 액세스는 읽기 모드로 유지됩니다.

어떤 경우에는 시운전(TE) 기간 동안 그리고 심지어 이 기간 이후에도 두 시스템의 병렬 작동이 발생할 수 있습니다. 두 시스템에서 사용자의 병렬 작업 문제는 마이그레이션(또는 일반적으로 새 시스템의 작동)이 만족스럽지 않다고 간주되는 경우 이전 시스템으로 롤백할 가능성 문제와 밀접한 관련이 있습니다.

결론

결론적으로, 많은 1C:Enterprise 구성을 포함하는 대규모 트랜잭션 시스템을 마이그레이션할 때 새로운 시스템으로의 전환은 매우 노동 집약적일 수 있다는 점에 주목하고 싶습니다.

따라서 이러한 프로젝트에는 세심한 준비가 필요하며 개별 계획이 수반되어야 한다는 점을 기억해야 합니다. 그러나 마이그레이션되는 시스템 유형, 데이터베이스 볼륨 등에 관계없이 일반적인 마이그레이션 구성표는 거의 동일해 보입니다.

  • 기존 리소스 도메인을 새 도메인의 조직 단위로 이전하여 네트워크 리소스 관리를 단순화합니다.
  • 실제 데이터 전송이 발생하지 않는 동안 마이그레이션 진행 상황을 "시뮬레이트"합니다.
  • 마이그레이션과 관련하여 수행된 작업을 실행 취소합니다.
  • 서비스 계정 이동
  • 복원하다 신뢰관계소스 도메인과 대상 도메인 사이
  • 이미 생성된 Active Directory 환경에서 여러 도메인을 하나 이상의 대규모 도메인으로 변환합니다.
  • 기존 그룹을 재구성하거나 여러 그룹을 대상 도메인에서 하나로 병합합니다.
  • 마이그레이션 이벤트를 기록하여 데이터 전송 프로세스를 분석합니다.

기존 액세스 권한을 유지하면서 사용자와 워크스테이션을 단일 Active Directory 구조로 마이그레이션합니다.

업그레이드 옵션

도메인 인프라를 업그레이드하는 데는 두 가지 주요 옵션이 있습니다[4].

  • 도메인 업데이트. 이 방법은 도메인을 마이그레이션할 때 가장 일반적이고 구현하기 쉬운 방법입니다. 이 방법을 사용하면 현재 도메인 구조, 시스템 설정, 사용자 및 그룹 구조를 저장할 수 있습니다. 도메인 업데이트(내부 업데이트)에는 기존 도메인 컨트롤러를 새로 생성된 도메인으로 이전하는 작업이 포함됩니다.
  • 도메인 구조 조정. 이 방법을 사용하면 도메인의 기존 구조를 변경하거나 도메인을 병합하거나 도메인을 조직 단위로 변환할 수 있습니다.

위의 옵션 외에도 이를 기반으로 하는 혼합 옵션도 있습니다. 즉, 후속 구조 조정으로 도메인을 업데이트하는 것입니다[13].

이러한 옵션을 Active Directory 구현을 위한 전환 경로. 이들 중에서 선택한 전환 경로는 도메인 인프라 업데이트를 위한 전체 전략의 주요 링크가 됩니다. 이 전략에는 이동해야 하는 디렉터리 서비스 개체와 순서에 대한 설명이 포함됩니다. Active Directory 구현 중 응용 프로그램 이동에 대한 가장 좋은 방법은 전환 계획이라는 작업 문서에 모든 세부 정보를 문서화하는 것입니다.

전환 경로 선택 기준

전환 경로를 선택할 때 결정은 하나의 도메인에만 관련되는 것으로 가정합니다. 즉, 동일한 조직 내의 다양한 도메인에 대해 서로 다른 전환 경로를 사용하는 것이 완전히 공평하다는 의미입니다.

표 12.1, 12.2, 12.3, 12.4, 12.5, 12.6에 제시된 가장 적합한 전환 경로[13]를 선택할 때 사용되는 주요 기준을 고려해 보겠습니다.

  • 기준 1. 기존 도메인의 기존 모델에 대한 만족. 표 12.1. 기준 1에 따라 전환 경로 선택
    전환 경로 자격 기준
    도메인 업데이트 도메인 모델에 적용할 중요한 변경 사항이 없으면 도메인을 업데이트하는 것이 가장 쉬운 경로를 제공합니다. 모든 사용자 및 그룹 계정의 존재와 마찬가지로 도메인 이름은 동일하게 유지됩니다.
    도메인 구조 조정 현재 도메인 모델이 더 이상 조직의 요구 사항을 충족하지 않거나 더 이상 조직의 부서에 가장 적합하지 않은 경우 도메인 구조 조정이 최선의 선택일 수 있습니다.
  • 기준 2. 새로운 도메인 모델로 전환할 때의 위험 정도. 표 12.2. 기준 2에 따라 전환 경로 선택
    전환 경로 자격 기준
    도메인 업데이트 도메인 업그레이드는 위험이 낮은 방법입니다. 도메인 컨트롤러 업그레이드 프로세스는 자동으로 진행되므로 사용자 개입 없이는 오류가 발생할 여지가 거의 없습니다. 도메인 업그레이드 실패로부터 복구하는 방법도 상대적으로 간단합니다. 업그레이드가 실패하면 주 도메인 컨트롤러(PDC)를 종료하고 새로운 데이터가 있는 백업 도메인 컨트롤러(BDC)를 PDC 역할에 할당해야 합니다. 절차를 다시 시작하세요
    도메인 구조 조정 도메인 구조 조정은 도메인 갱신보다 위험이 더 높습니다. 완료해야 할 작업이 더 많기 때문에 많은 프로세스가 잘못될 수 있습니다. 그 결과, 로그인할 수 없거나 필요한 리소스에 액세스할 수 없거나 사서함에 액세스할 수 없는 사용자들 사이에서 불만이 커지고 있습니다.
  • 기준 3. 전환 1 실행 시간 전환 시기는 전환 경로를 선택하는 데 결정적인 요소가 아니지만, 리소스가 제한된 소규모 조직에서는 결정적인 요소가 될 수 있습니다. .표 12.3. 기준 3에 따라 전환 경로 선택
    전환 경로 자격 기준
    도메인 업데이트 도메인 갱신은 선형 프로세스입니다. 일단 시작된 후에는 완료해야 합니다. 구조 조정보다 단계가 적으므로 전체 전환을 완료하는 데 시간이 덜 걸립니다.
    도메인 구조 조정 도메인 구조 조정은 항상 더 오래 걸립니다. 예를 들어 구조 조정 중에 대상 도메인의 인프라를 구축 및 검증하고 모든 계정을 원본 도메인에서 대상 도메인으로 이동하는 데 많은 시간이 소요됩니다. 대규모 조직에서는 모든 개체를 한 번에 이동할 수 없으므로 도메인 재구성이 여러 단계에 걸쳐 수행되는 경우가 많습니다.
  • 기준 4: 마이그레이션 프로세스를 완료하는 데 필요한 디렉터리 서비스 시간입니다. 표 12.4. 기준 4에 따라 전환 경로 선택
    전환 경로 자격 기준
    도메인 업데이트 계정 개체는 도메인이 업그레이드될 때 자동으로 업데이트되므로 마이그레이션 프로세스 중에는 사용할 수 없습니다.
    도메인 구조 조정 시스템 작업 시간이 중요한 가치인 조직에 적합한 선택입니다. 여기에는 채워지지 않은 "깨끗한" 포리스트를 생성하고 원래 환경을 본질적으로 변경하지 않고 그대로 두기 때문에 사용자가 기존 환경에서 계속 기능할 때 디렉터리 서비스의 기능이 보존됩니다. 사용량이 적은 시간에 대규모 또는 소규모 사용자 배치를 마이그레이션하고 기존 시스템을 떠날 준비가 될 때까지 이러한 새 계정을 휴면 상태로 둘 수 있습니다.
  • 기준 5. 전환을 완료하는 데 필요한 자원의 가용성. 표 12.5. 기준 5에 따라 전환 경로 선택
    전환 경로 자격 기준
    도메인 업데이트 도메인 업데이트는 자동화된 작업이므로 이 전환 경로에는 더 적은 인적 자원이 필요합니다.
    도메인 구조 조정 도메인 재구성에는 도메인 갱신보다 더 많은 작업이 수반되므로 더 많은 리소스가 필요합니다. 즉, 도메인 재구성과 관련된 추가 작업량을 처리하려면 적절한 인력이 필요합니다. 대안은 프로젝트의 일부 또는 전부를 아웃소싱하는 것입니다. 이러한 프로젝트를 전문으로 하는 컨설팅 그룹이 많이 있으므로 내부 직원 교육에 필요한 시간과 비용을 절약할 수 있습니다.
  • 기준 6. 전환 프로젝트 예산. 표 12.6. 기준 5에 따라 전환 경로 선택
    전환 경로 자격 기준
    도메인 업데이트 필요한 예산 자금 감소에 기여하는 요인:
    • 기존 서버 하드웨어를 사용할 수 있는 능력;
    • 인적 자원 비용 절감;
    • 테스트해야 하는 업그레이드 작업이 줄어들기 때문에 테스트 비용이 절감됩니다.
    도메인 구조 조정 여러 가지 이유로 도메인 구조 조정에는 도메인 갱신보다 더 많은 예산이 필요합니다. 디렉터리 서비스 개체를 마이그레이션해야 하는 베어 포리스트 환경을 구축하는 데 필요한 하드웨어 요구 사항은 예산 측면에서 고려해야 합니다.

회사가 자신있게 도메인 갱신 또는 구조 조정을 갱신 경로로 선택할 수 있는 조건을 충족하지 못하거나 두 경로가 모두 적합한 경우 도메인 갱신과 구조 조정이 뒤따르는 세 번째 경로를 선택할 수 있습니다.

Active Directory에 대한 이 경로는 즉각적인 이점을 제공합니다(관리 위임, 그룹 정책, 애플리케이션 게시 등) 및 도메인 재구성의 장기적인 이점(도메인 볼륨 증가로 도메인 수 감소, 회사의 비즈니스 및 조직 목표에 따른 도메인 설계)을 제공합니다.