구성 확인

DR 설정이 완료되면 즉시 완전한 스위치오버를 수행하거나 보조 사이트에서 검증을 열어 설정이 올바른지 검증합니다. 검증을 위해 보조 사이트를 열면 주 사이트에서 실행 중인 시스템에 영향을 주지 않습니다.

검증을 위해 2차 항목 열기

standby database를 snapshot standby로 변환하여 complete switchover를 수행하지 않고 standby 사이트를 검증할 수 있습니다. 이렇게 하면 보조 SOA 서버를 대기 사이트에서 시작하고 보조 시스템을 확인할 수 있습니다. {\f2732 snapshot standby }모드일 때{\f2732 standby }사이트 데이터베이스에서 수행된 모든 변경 사항은 물리적{\f2732 standby database}로 다시 변환되면 폐기됩니다{\f2732 .} 기본 데이터가 보조 사이트 검증의 영향을 받지 않습니다.

참고:

이 작업은 주의해서 수행해야 합니다. 스냅샷으로 변환될 때 데이터베이스에 보류 중인 메시지나 조합이 있을 경우 대기 사이트의 SOA 서버가 시작될 때 이를 처리합니다. 스냅샷 대기로 변환할 때 기본 데이터베이스에 보류 중인 작업이 없는지 확인하십시오. 그렇지 않으면 스냅샷 대기 데이터베이스로 변환된 후 보조 사이트의 SOA 서버를 시작하기 전에 대기 데이터베이스의 런타임 SOA 테이블에서 레코드를 제거합니다. 전환을 수행하지 않고 대기 사이트를 검증하는 단계는 테이블을 삭제하지 않고 런타임 테이블에서 레코드 제거를 참조하십시오.
  1. oracle 사용자로 기본 db 호스트에서 Oracle Data Guard 브로커를 사용하고 보조를 스냅샷 대기로 변환합니다.
    [oracle@dbhost1~]$ dgmgrl sys/your_sys_password@primary_db_unqname
    DGMGRL> convert database secondary_db_unqname to snapshot standby
    
    show configuration 명령을 사용하여 변환이 올바르게 수행되었는지 확인합니다.
  2. 보조 환경에 보류 중인 작업이 없는지 확인합니다.
    대기가 스냅샷으로 변환될 때 기본 DB에 보류 중인 작업(트랜잭션, 메시지)이 있을 경우 보조 SOA 서버는 start.You가 SOA 잘라내기 스크립트를 사용하여 보조 서버의 SOA 런타임 테이블에서 레코드를 제거하여 보조 서버를 시작하기 전에 런타임 데이터를 정리할 수 있을 때 해당 작업을 처리하려고 시도합니다. 이 작업은 주 데이터베이스에서 테이블을 잘라내지 않도록 주의하여 실행하십시오. 테이블을 삭제하지 않고 런타임 테이블에서 레코드 제거를 참조하십시오.
  3. 아직 작동 중이지 않은 경우 보조 사이트에서 Oracle HTTP Server 시스템을 시작합니다.
  4. 보조 사이트에서 관리 서버를 시작합니다.
  5. 보조 사이트에서 보조 관리 서버를 시작합니다.
    WebLogic 콘솔 또는 스크립트를 사용하여 보조 관리 서버를 시작합니다.
  6. 보조 사이트를 검증합니다.

    이 이름은 스위치오버가 아니며 기본 사이트가 여전히 활성 상태이므로, 가상 프론트 엔드 이름은 기본 사이트의 로드 밸런서 IP 주소로 확인되므로 모든 브라우저 액세스는 기본적으로 활성 기본 사이트로 재지정됩니다.

    보조 사이트의 SOA 서비스에 직접 액세스하려면 제어된 클라이언트(예: 랩탑)에서 /etc/hosts 파일을 업데이트하고, 보조 사이트의 프론트 엔드 로드 밸런서 IP 주소로 분석하도록 가상 프론트 엔드 이름을 설정하고, 이 클라이언트에서 검증을 실행해야 합니다.

    참고:

    HTTP 프록시가 클라이언트의 /etc/hosts에 있는 이름에 관계없이 기본 사이트의 로드 밸런서 IP 주소로 가상 프론트 엔드 이름을 계속 확인할 수 있으므로 검증에 사용된 클라이언트가 HTTP 프록시를 통해 시스템에 액세스하지 않는지 확인합니다.

    비Linux 클라이언트의 경우 브라우저가 사용자 정의된 호스트 파일 항목을 사용하여 IP 주소를 분석하기 전에 로컬 DNS 캐시를 재설정해야 할 수 있습니다.

    보조 사이트가 검증되면 다음 단계로 이동하여 대기 역할로 되돌립니다.

    참고:

    보조 사이트를 검증하는 데 시간이 걸릴 수 있습니다.
  7. 보조 사이트에서 관리 서버와 관리 서버를 중지합니다.
    보조 WebLogic 콘솔을 사용하여 보조 사이트에서 관리 서버 및 관리 서버를 종료합니다.
  8. oracle 사용자로 primary 데이터베이스 호스트에서 Oracle Data Guard 브로커를 사용하고 보조를 물리적 대기로 다시 변환합니다.
    기본 데이터베이스의 고유한 이름과 시스템 비밀번호가 필요합니다.
    [oracle@dbhost1 ~]$ dgmgrl sys/your_sys_password@primary_db_unqname
        DGMGRL> convert database secondary_db_unqname to physical standby
    변환을 확인하려면 show configuration을 사용합니다.
  9. 업데이트된 /etc/hosts 파일을 되돌립니다.
    검증을 위해 보조 사이트를 가리키도록 클라이언트의 /etc/hosts 파일을 업데이트한 경우 가상 프론트 엔드 이름이 기본 프론트 엔드 IP 주소를 다시 가리키도록 되돌립니다.

참고:

ORA-01403: 데이터를 찾을 수 없음 ORA-06512 오류

여기서 설명한 대로 보조 사이트를 검증하는 동안(전체 스위치오버를 수행하지 않고, 즉 스냅샷 대기 모드로 대기를 여는 것) "ORA-01403: 발견된 데이터가 없음 ORA-06512" 오류가 대기 SOA 서버의 로그에 표시될 수 있습니다. 이러한 오류는 SOA 자동 비우기 작업과 관련이 있습니다. 이 오류는 데이터베이스의 작업에 db 롤 종속성이 있을 수 있기 때문에 발생합니다. 이 오류는 데이터베이스가 기본 롤에 있는 경우에만 활성화되도록 정의됩니다. 이는 작업이 두 번(기본 및 대기 데이터베이스에서 한 번) 실행되지 않도록 방지하는 예상 동작입니다. SOA 자동 비우기 작업은 기본 역할로 정의되므로 데이터베이스가 스냅샷 대기 모드에 있을 때 DBA_SCHEDULER_JOBS 뷰에 표시되지 않습니다. 각 작업에 대해 정의된 database_role는 DBA_SCHEDULER_JOB_ROLE 뷰에서 볼 수 있습니다. 요약하자면 이러한 오류는 대기 시스템에 나타나는 한 무시해도 됩니다. SOA 자동 비우기의 스케줄러 작업은 인스턴스가 롤을 PRIMARY로 변경하는 경우에만 데이터베이스에서 실행됩니다.

Switchover 수행

전환은 관리자가 두 사이트의 롤을 되돌리는 계획된 작업입니다. 스위치오버 후에 기본 시스템은 보조 시스템이 되고 보조 시스템은 기본 시스템이 됩니다. switchover를 수행하면 기본 사이트에서 작동 중지 시간이 발생합니다.
SOA 하이브리드 DR 구성에서 스위치오버를 수행하기 전에 보류 중인 구성 변경 사항을 전파합니다. 보류 중인 보조 사이트에 복제된 변경사항이 없는지 확인합니다.
  1. switchover가 수행되는 동안 예약된 복제를 사용 안함으로 설정하면 작업이 실패하고 스위치오버 작업 자체를 방해할 수 있습니다.
  2. 기본 사이트에서 Oracle HTTP Server 시스템을 정지합니다.
  3. 기본 사이트에서 서버를 중지합니다.
    WebLogic 관리 서버 콘솔 또는 스크립트를 사용하여 기본 사이트의 WebLogic 서버를 중지합니다.

    참고:

    기본 사이트의 관리 서버는 스위치오버 중에 계속 작동할 수 있습니다. 하지만 사이트가 대기 롤일 때 중지하는 것이 좋습니다. 대기 사이트의 도메인 구성이 수명 주기 동안 기본 구성으로 무효화될 것으로 예상되기 때문입니다. 이 경우 관리 서버가 작동 중인 경우 사용되지 않는 구성으로 실행됩니다.
  4. 프론트 엔드 DNS 이름을 스위치오버합니다.

    시스템에서 사용하는 이름을 호스트하는 DNS 서버에서 필요한 DNS 푸시를 수행하거나 클라이언트의 파일 호스트 확인을 변경하여 시스템의 프론트 엔드 가상 이름을 보조 사이트의 로드 밸런서가 사용하는 공용 IP로 가리킵니다.

    DNS가 외부 프런트엔드 분석(예: OCI DNS 또는 상용 DNS)에 사용되는 시나리오의 경우 API를 사용하여 변경 사항을 푸시할 수 있습니다. OCI DNS에서 이 변경사항을 푸시하는 예를 보려면 GitHub(예: 스크립트)로 이동하십시오.

    DNS 항목의 TTL 값은 스위치오버의 RTO에 영향을 미칩니다. TTL이 높을 경우(예: 20분) DNS 변경사항은 클라이언트에서 해당 시간을 적용합니다. TTL 값을 낮추면 이 속도는 빨라지지만 클라이언트가 캐시된 이름을 사용하는 대신 DNS에 더 자주 도달하기 때문에 오버헤드가 발생할 수 있습니다. 좋은 방법은 DNS를 변경하기 전에 TTL을 일시적으로 낮은 값(예: 1분)으로 설정하는 것입니다. 그런 다음 변경 작업을 수행하고 스위치오버 절차가 완료되면 TTL을 원래 값으로 다시 되돌립니다.

  5. oracle 사용자로 기본 데이터베이스 호스트에서 Oracle Data Guard 브로커를 사용하여 데이터베이스 전환을 수행합니다.
    기본 데이터베이스의 고유한 이름과 시스템 비밀번호가 필요합니다.
    [oracle@dbhost1~]$ dgmgrl sys/your_sys_password@primary_db_unqname
    DGMGRL> switchover to secondary_db_unqname
  6. 아직 작동 중이지 않은 경우 보조 사이트(새 기본 사이트)에서 Oracle HTTP Server 시스템을 시작합니다.
  7. 보조 사이트(새 기본 서버)에서 관리 서버를 시작하거나 서버가 이미 시작된 경우 서버를 다시 시작합니다.
    관리 서버를 시작하면 대기 상태였던 동안 복제된 구성 변경 사항이 적용됩니다.
  8. 보조 사이트(새로운 기본 서버)에서 보조 관리 서버를 시작합니다.
    WebLogic 콘솔 또는 스크립트를 사용하여 보조 관리 서버를 시작합니다.