지금 지원 담당자와 채팅
지원 담당자와 채팅

SharePlex 11.4 - 관리 안내서

이 안내서 정보 이 안내서에 사용된 규칙 SharePlex 개요 SharePlex 실행 SharePlex의 여러 인스턴스 실행 sp_ctrl에서 명령 실행 SharePlex 매개변수 설정 데이터 복제 구성 컨테이너 데이터베이스와의 복제 구성 명명된 큐 구성 파티셔닝된 복제 구성 변경 내역 타겟에 대한 복제 구성 복제 전략 구성 DDL 복제 구성 오류 처리 구성 데이터 변환 구성 보안 기능 구성 SharePlex 사용자를 보안 그룹에 할당 프로덕션 시스템에서 복제 시작 SharePlex 모니터링 복제 문제 방지 및 해결 동기화 중단 데이터 복원 Capture 프로세스 조정 Post 프로세스 조정 Oracle 장애 조치 후 복제 복구 활성 복제 환경 변경 Oracle 애플리케이션 패치 또는 업그레이드 적용 소스 또는 타겟에서 Oracle 데이터 백업 문제 해결 팁 부록 A: 피어-투-피어 다이어그램 부록 B: SharePlex 환경 변수

SharePlex 준비 루틴

SharePlex는 사용자 지정 루틴과 함께 사용할 준비 루틴(선택 사항)을 제공합니다. 이러한 옵션은 기본 및 일반 충돌 해결 형식과 함께 사용할 수 있습니다. 컬럼 유형에는 제한이 없습니다.

데이터베이스에서 기본 키와 유니크 키의 추가 로깅을 활성화해야 합니다.

지원되는 소스 및 타겟 데이터베이스 조합

  • 오라클 간 마이그레이션

  • PostgreSQL-PostgreSQL

  • PostgreSQL-Oracle

  • PostgreSQL Database as a Service-PostgreSQL Database as a Service

  • PostgreSQL Database as a Service-Oracle

  • PostgreSQL Database as a Service-PostgreSQL

고려 사항

SharePlex 준비 루틴을 구현하기 전에 다음 고려 사항을 검토합니다.

!HostPriority

이 충돌 해결 준비 루틴은 INSERT, UPDATE 및 DELETE 작업에 작동합니다. 이 루틴은 신뢰할 수 있는 소스 시스템에서 발생한 행 변경에 우선순위를 할당하여 호스트 기반 충돌 해결을 제공합니다. 신뢰할 수 있는 소스를 정의하려면 SP_OPO_TRUSTED_SOURCE(Oracle 소스) 또는 SP_OPX_TRUSTED_SOURCE(PostgreSQL 소스) 매개변수를 소스 시스템의 이름으로 설정합니다.

해결 논리
작업 해결 방법

INSERT

SP_OPO_TRUSTED_SOURCE(Oracle 소스) 또는 SP_OPX_TRUSTED_SOURCE(PostgreSQL 소스)로 지정된 소스인 경우 INSERT를 UPDATE로 변환하고 기존 행을 덮어씁니다.

해당 소스가 아닌 경우 변경 레코드를 삭제하고 타겟 행에 아무 작업도 수행하지 않습니다.

UPDATE

SP_OPO_TRUSTED_SOURCE(Oracle 소스) 또는 SP_OPX_TRUSTED_SOURCE(PostgreSQL 소스)로 지정된 소스인 경우 UPDATE를 사용하여 기존 행을 덮어쓰고 WHERE 절의 키 컬럼만 사용합니다. 해당 소스가 아닌 경우 변경 레코드를 삭제하고 타겟 행에 아무 작업도 수행하지 않습니다.

DELETE 동기화 중단 오류를 무시하고 타겟 행에 아무 작업도 수행하지 않습니다.
충돌 해결 파일의 구문
owner.table {I | U | D} !HostPriority

!LeastRecentRecord

이 준비 루틴은 INSERT, UPDATE 및 DELETE 작업에 작동합니다. 타임스탬프에 따라 결정된 최소한의 최근 행 변경 사항에 우선순위를 할당하여 시간 기반 충돌 해결을 제공합니다.

타임스탬프를 캡처하려면 이 루틴을 사용하는 테이블에 테이블의 모든 INSERT 및 UPDATE로 업데이트되는 NULL이 아닌 타임스탬프 컬럼이 있어야 합니다. DML 또는 기존 행의 타임스탬프 컬럼이 NULL인 경우 이 루틴은 충돌을 해결할 수 없습니다.

이 루틴을 사용하려면 소스 시스템에서 Oracle의 경우 SP_OCT_REDUCED_KEY 매개변수, PostgreSQL의 경우 SP_CAP_REDUCED_KEY 매개변수를 0으로 설정해야 UPDATES의 모든 사전 이미지 값을 Post 프로세스에서 사용할 수 있습니다.

해결 논리
작업 해결 방법

INSERT

및

UPDATE
  • 복제된 작업의 타임스탬프 컬럼 값이 타겟 행의 타임스탬프 컬럼보다 크거나 같은 경우 복제된 작업을 삭제하고 타겟 행에 아무 작업도 수행하지 않습니다.
  • 복제된 작업의 타임스탬프 컬럼이 타겟 행의 타임스탬프 컬럼보다 작은 경우 UPDATE를 사용하여 기존 행을 덮어쓰고 WHERE 절의 키 컬럼만 사용합니다.
DELETE 충돌(동기화 중단 메시지)을 무시합니다.
충돌 해결 파일의 구문
owner.table {I | U | D} !LeastRecentRecord(col_name)

여기서, col_name은 루틴에서 사용할 타임스탬프 컬럼입니다.

참고:

  • DATE 데이터 유형은 시간 값을 저장하지 않기 때문에 PostgresSQL 데이터베이스의 col_name에 권장되는 데이터 유형은 타임스탬프입니다. 결과적으로 날짜 데이터 유형을 사용하는 경우 두 피어에서 동시에 동일한 날짜가 업데이트되면 충돌이 해결되지 않습니다.

  • Oracle 피어에 대한 col_name의 대소문자 구분은 소스 데이터베이스에 따라 다릅니다.

    • 데이터가 Oracle에서 Oracle로 복제되는 경우 col_name은 대문자여야 합니다.

    • 데이터가 PostgreSQL에서 Oracle로 복제되는 경우 col_name은 소문자여야 합니다.

    • 데이터가 Oracle 및 PostgreSQL 소스 모두에서 Oracle로 복제되는 경우 col_name에 대한 충돌 해결 루틴의 두 가지 항목(대문자와 소문자)이 있어야 합니다.

!MostRecentRecord

이 준비 루틴은 INSERT, UPDATE 및 DELETE 작업에 작동합니다. 타임스탬프에 따라 결정된 최대한의 최근 행 변경 사항에 우선순위를 할당하여 시간 기반 충돌 해결을 제공합니다.

타임스탬프를 캡처하려면 이 루틴을 사용하는 테이블에 테이블의 모든 INSERT 및 UPDATE로 업데이트되는 NULL이 아닌 타임스탬프 컬럼이 있어야 합니다. DML 또는 기존 행의 타임스탬프 컬럼이 NULL인 경우 이 루틴은 충돌을 해결할 수 없습니다.

이 루틴을 사용하려면 소스 시스템에서 Oracle의 경우 SP_OCT_REDUCED_KEY 매개변수, PostgreSQL의 경우 SP_CAP_REDUCED_KEY 매개변수를 0으로 설정해야 UPDATES의 모든 사전 이미지 값을 Post 프로세스에서 사용할 수 있습니다.

해결 논리
작업 해결 방법

INSERT

및

UPDATE
  • 복제된 작업의 타임스탬프가 타겟 행의 타임스탬프보다 큰 경우 UPDATE를 사용하여 기존 행을 덮어쓰고 WHERE 절의 키 컬럼만 사용합니다.
  • 복제된 작업의 타임스탬프가 타겟 행의 타임스탬프보다 작거나 같은 경우 변경 레코드를 삭제하고 타겟 행에 아무 작업도 수행하지 않습니다.
DELETE 충돌(동기화 중단 메시지)을 무시합니다.
충돌 해결 파일의 구문
owner.table {I | U | D} !MostRecentRecord(col_name)

여기서, col_name은 루틴에서 사용할 타임스탬프 컬럼입니다.

참고:

  • DATE 데이터 유형은 시간 값을 저장하지 않기 때문에 PostgresSQL 데이터베이스의 col_name에 권장되는 데이터 유형은 타임스탬프입니다. 결과적으로 날짜 데이터 유형을 사용하는 경우 두 피어에서 동시에 동일한 날짜가 업데이트되면 충돌이 해결되지 않습니다.

  • Oracle 피어에 대한 col_name의 대소문자 구분은 소스 데이터베이스에 따라 다릅니다.

    • 데이터가 Oracle에서 Oracle로 복제되는 경우 col_name은 대문자여야 합니다.

    • 데이터가 PostgreSQL에서 Oracle로 복제되는 경우 col_name은 소문자여야 합니다.

    • 데이터가 Oracle 및 PostgreSQL 소스 모두에서 Oracle로 복제되는 경우 col_name에 대한 충돌 해결 루틴의 두 가지 항목(대문자와 소문자)이 있어야 합니다.

!UpdateUsingKeyOnly

이 루틴은 UPDATE 작업에 작동합니다. 또한 변경된 행의 키 값에만 사용하는 충돌 해결을 제공합니다. 일반적으로 SharePlex가 데이터를 게시하기 위해 SQL 문을 빌드할 때 WHERE 절은 동기화를 보장하기 위해 변경된 컬럼의 키와 사전 이미지를 모두 사용합니다. !UpdateUsingKeyOnly 루틴은 키가 일치한다고 가정하고 사전 이미지 값이 일치하지 않더라도 데이터를 게시하도록 SharePlex에 지시합니다.

해당하는 경우 이 루틴을 UPDATE의 유일한 루틴으로 사용할 수 있지만 동시 UPDATE가 여러 개인 경우 우선순위(시스템 우선순위, 시간 우선순위 등)를 할당하는 논리가 포함되지 않는다는 점을 이해해야 합니다. 동기화 중단 오류를 방지하기 위해 Quest에서는 !UpdateUsingKeyOnly를 보다 구체적인 다른 루틴과 함께 사용하고, 사용자 지정 루틴이 실패할 경우 최종 옵션으로 !UpdateUsingKeyOnly를 사용하는 것을 권장합니다.

중요:!UpdateUsingKeyOnly는 루틴 목록의 마지막 항목이어야 하므로 마지막 우선순위를 지정해야 합니다.

다음 예에서는 UPDATE 중에 owner.table1에 충돌이 있는 경우 SharePlex가 두 개의 사용자 지정 루틴을 먼저(우선순위에 따라) 호출한 다음, !UpdateUsingKeyOnly 루틴을 호출합니다.

owner.table1 u owner.procedure_up_A
owner.table1 u owner.procedure_up_B
owner.table1 u !UpdateUsingKeyOnly

!UpdateUsingKeyOnly 이름은 대소문자를 구분합니다. 이 지침에 나온 대로 단어 사이에 공백 없이 정확하게 입력해야 합니다. 구성 파일에 이 루틴을 사용하여 소유자 이름을 나열하지 마십시오. INSERT 및 DELETE 작업의 경우 사용자 지정 논리를 사용해야 합니다.

Oracle 데이터베이스에 대해 해결된 충돌에 관한 로그 정보

SharePlex 준비 루틴을 사용하는 경우 성공적인 충돌 해결 작업에 대한 정보를 기록하도록 Post 프로세스를 구성할 수 있습니다. 이 기능은 기본적으로 비활성화되어 있습니다.

충돌 해결 로깅을 활성화하려면 다음을 수행합니다.

  1. 타겟 시스템에서 sp_ctrl을 실행합니다.

  2. 다음 명령을 실행합니다.

    sp_ctrl> set param SP_OPO_LOG_CONFLICT {1 | 2}

    • 1로 설정하면 SHAREPLEX_CONF_LOG 테이블에 대한 충돌 해결 로깅이 활성화됩니다.

      참고: 1로 설정하면 SHAREPLEX_CONF_LOG 테이블의 EXISTING_TIMESTAMP 및 TARGET_ROWID 컬럼이(기존 데이터가 교체되지 않은 경우) 업데이트되지 않습니다.

    • 2로 설정하면 추가 메타데이터에 대한 Post 쿼리를 사용하여 SHAREPLEX_CONF_LOG 테이블에 충돌 해결을 기록할 수 있습니다.

      LeastRecentRecord 또는 MostRecentRecord 준비 루틴을 사용하면 Post는 기존 레코드의 타임스탬프 컬럼에 대해 타겟 데이터베이스를 쿼리합니다. 쿼리 결과는 SHAREPLEX_CONF_LOG 테이블의 EXISTING_TIMESTAMP 컬럼에 기록됩니다.

      준비된 루틴의 경우 들어오는 레코드로 대체되지 않는 행에서 Post는 대체될 수 있는 기존 행의 TARGET_ROWID를 쿼리합니다. 준비되지 않은 경우 기존 행의 ROWID가 기록되지 않습니다.

      참고: 2로 설정하면 쿼리 결과로 인해 Post 성능에 영향을 미칠 수 있습니다.

  3. Post를 재시작합니다.

Post는 SHAREPLEX_CONF_LOG라는 테이블에 정보를 기록합니다. 다음은 이 표에 대한 설명입니다.

컬럼 컬럼 정의 기록되는 정보
CONFLICT_NO NUMBER NOT NULL 해결된 충돌의 고유 식별자입니다. 이 값은 shareplex_conf_log_seq 시퀀스에서 생성됩니다.
CONFLICT_TIME TIMESTAMP DEFAULT SYSTIMESTAMP 충돌 해결의 타임스탬프입니다.
CONFLICT_TABLE VARCHAR2(100) 충돌과 관련된 타겟 테이블의 이름입니다.
CONFLICT_TYPE VARCHAR2(1) 충돌 유형(삽입의 경우 I, 업데이트의 경우 U, 삭제의 경우 D)입니다.
CONFLICT_RESOLVED VARCHAR2(1) NOT NULL

충돌이 해결되었는지 여부를 나타내는 표시입니다.

Y = 예. 충돌이 해결되었습니다.

N = 아니요. 충돌이 해결되지 않았습니다. 해결되지 않은 충돌은 ID_errlog.sql 파일에 기록되며 여기서, ID는 소스 데이터베이스 식별자입니다.

TIMESTAMP_COLUMN VARCHAR2(50) 어떤 레코드가 가장 최근 상태인지 확인하기 위해 Post가 비교한 타임스탬프가 포함된 컬럼의 이름입니다.
INCOMING_TIMESTAMP DATE 소스 시스템에서 행이 삽입, 업데이트 또는 삭제된 타임스탬프입니다.
EXISTING_TIMESTAMP DATE 타겟 데이터베이스에 있는 행의 현재 타임스탬프입니다. SP_OPO_LOG_CONFLICT 매개변수가 2로 설정된 경우에만 적용되며, 이 값을 얻기 위해 타겟 데이터베이스를 쿼리하도록 Post에 지시합니다.
PRIMARY_KEYS VARCHAR2(4000) 기본 키 컬럼의 이름입니다.
메시지 VARCHAR2(400)

충돌에서 어느 행이 우선시되는지 알려주는 메시지입니다. 우선시되는 행은 어떤 충돌 해결 루틴이 사용되었는지에 따라 달라집니다. 예를 들어 !MostRecentRecord 루틴이 사용되고 가장 최근 레코드가 소스 레코드인 경우 다음과 같은 메시지가 반환됩니다.

Incoming timestamp > existing timestamp. Incoming wins, overwrite existing.

타겟 레코드가 가장 최근 레코드이거나 소스 레코드와 타임스탬프가 동일한 경우 메시지는 다음과 같습니다.

Incoming timestamp <= existing timestamp. Existing wins, discard incoming.

SQL_STATEMENT LONG 충돌 해결 결과 실행된 최종 SQL 문입니다.
CONFLICT_CHECKED VARCHAR2(1) 누군가 충돌을 검토했는지 여부를 나타냅니다. 기본값은 아니요의 경우 N입니다. 충돌을 검토하는 사용자는 이 값을 Y로 변경할 수 있습니다.

PostgreSQL 데이터베이스에 대해 해결된 충돌에 관한 로그 정보

SharePlex 준비 루틴을 사용하는 경우 성공적인 충돌 해결 작업에 대한 정보를 기록하도록 Post 프로세스를 구성할 수 있습니다. 이 기능은 기본적으로 비활성화되어 있습니다.

충돌 해결 로깅을 활성화하려면 다음을 수행합니다.

  1. 타겟 시스템에서 sp_ctrl을 실행합니다.

  2. 다음 명령을 실행합니다.

    sp_ctrl> set param SP_OPX_LOG_CONFLICT {1 | 2}

    • 1로 설정하면 shareplex_conf_log 테이블에 대한 충돌 해결 로깅이 활성화됩니다.

      참고: 1로 설정하면 shareplex_conf_log 테이블의 existing_timestamp 컬럼이(기존 데이터가 교체되지 않은 경우) 업데이트되지 않습니다.

    • 2로 설정하면 추가 메타데이터에 대한 Post 쿼리를 사용하여 shareplex_conf_log 테이블에 충돌 해결을 기록할 수 있습니다.

      LeastRecentRecord 또는 MostRecentRecord 준비 루틴을 사용하면 Post는 기존 레코드의 타임스탬프 컬럼에 대해 타겟 데이터베이스를 쿼리합니다. 쿼리 결과는 shareplex_conf_log 테이블의 existing_timestamp 컬럼에 기록됩니다.

      참고: 2로 설정하면 쿼리 결과로 인해 Post 성능에 영향을 미칠 수 있습니다.

  3. Post를 재시작합니다.

Post는 shareplex_conf_log라는 테이블에 정보를 기록합니다. 다음은 이 표에 대한 설명입니다.

컬럼 컬럼 정의 기록되는 정보
conflict_no bigserial primary key 해결된 충돌의 고유 식별자입니다. 이 값은 shareplex_conf_log_conflict_no_seq 시퀀스에서 생성됩니다.
conflict_time timestamp 충돌 해결의 타임스탬프입니다.
src_host varchar(64) 소스 호스트의 호스트 이름입니다.
curr_host varchar(64) 현재 호스트의 호스트 이름입니다.
trusted_host varchar(64) 신뢰할 수 있는 호스트의 호스트 이름입니다. !HostPriority 준비 루틴의 경우에 사용됩니다.
src_db varchar(150) 소스 데이터베이스 이름입니다.
source_rowid varchar(20) 소스 테이블 rowid입니다. PostgreSQL 소스의 경우 이 컬럼은 해당되지 않습니다. 해당 값은 N/A입니다.
target_rowid varchar(20) 타겟 테이블 rowid입니다. PostgreSQL 타겟의 경우 이 컬럼은 해당되지 않습니다. 해당 값은 N/A입니다.
conflict_table varchar(300) 충돌과 관련된 타겟 테이블의 이름입니다.
conflict_type char(1) 충돌 유형(삽입의 경우 I, 업데이트의 경우 U, 삭제의 경우 D)입니다.
conflict_resolved char(1) not null

충돌이 해결되었는지 여부를 나타내는 표시입니다.

Y = 예. 충돌이 해결되었습니다.

N = 아니요. 충돌이 해결되지 않았습니다. 해결되지 않은 충돌은 ID_errlog.sql 파일에 기록되며 여기서, ID는 소스 데이터베이스 식별자입니다.

odbc_error varchar(20) 충돌을 일으킨 odbc 오류를 나타냅니다. 형식은 <native error>:<error sqlstate>입니다.

중간 시스템을 통한 복제 설정

이 지침에서는 단계화 복제(다중 계층 복제라고도 함)를 설정하는 방법을 보여줍니다. 이 전략은 소스 시스템에서 중간 시스템으로 데이터를 복제한 다음, 중간 시스템에서 하나 이상의 원격 타겟 시스템으로 데이터를 복제합니다.

단계화 복제를 사용하면 다음과 같은 상황에서 해결 방법으로 다양한 복제 목표를 지원할 수 있습니다.

  • 지정된 소스 시스템에서 직접 허용되는 1024개 경로를 복제 전략이 초과합니다. 중간 시스템으로 데이터를 보낸 다음, 거기에서 추가 타겟으로 브로드캐스트할 수 있습니다.
  • 방화벽 제한이나 기타 요인으로 인해 소스가 최종 타겟에 직접 연결되지 않습니다. 소스 시스템에서 원격 연결을 허용하는 시스템에 단계화할 수 있습니다.

단계화 전략을 사용하려면 소스 시스템에서 최종 타겟 시스템 이름을 확인할 수 있어야 하며, 직접 연결을 만드는 기능은 필요하지 않습니다.

지원되는 소스

Oracle 및 PostgreSQL

지원되는 타겟

Oracle

Oracle 및 Open Target(최종 타겟)

기능

이 복제 전략은 다음을 지원합니다.

  • 하나 이상의 타겟 시스템에 대한 복제
  • 동일하거나 다른 소스 및 타겟 이름
  • 수직으로 파티셔닝된 복제 사용
  • 수평으로 파티셔닝된 복제 사용
  • 명명된 익스포트 및 Post 큐 사용

요구 사항

  • 지침에 따라 시스템을 준비하고, SharePlex를 설치하고, 데이터베이스 계정을 구성합니다(참조: SharePlex 설치 안내서).

    중요! 중간 시스템의 데이터베이스에 게시하기 위해 SharePlex를 사용하려는 경우 모든 시스템에서 동일한 SharePlex 사용자를 생성합니다.

  • 타겟 객체에 대해 DML을 수행하는 트리거를 비활성화합니다.

  • SharePlex를 제외하고는 타겟 테이블에서 DML이나 DDL을 수행하면 안 됩니다. 복제 구성 외부에 있는 타겟 시스템의 테이블은 복제에 영향을 주지 않고 DML 및 DDL 작업을 수행할 수 있습니다.

  • 타겟 시스템에 시퀀스가 불필요한 경우에는 복제하지 마십시오. 시퀀스를 복제하면 복제 속도가 느려질 수 있습니다. 소스 테이블에서 키를 생성하는 데 시퀀스가 사용되는 경우에도 복제된 행이 타겟 시스템에 삽입될 때의 시퀀스 값은 키 컬럼의 일부입니다. 시퀀스 자체는 복제할 필요가 없습니다.

DDL 복제 지원

중간 시스템을 통한 소스에서 타겟으로의 DDL 복제는 다음의 사항을 제외하고 관리 안내서의 SharePlex가 지원하는 DDL 장에 있는 정보에 따라 지원됩니다.

  • 소스가 아닌 중간 시스템에서 시작된 DDL은 불일치로 인한 Post 오류를 발생시키므로 DDL이 모든 시스템에서 동기화되지 않는 한 피해야 합니다.
  • 중간 시스템의 지연 시간이나 오류로 인해 불일치가 발생하지 않도록 모든 시스템을 모니터링해야 합니다.

중요! 이 지침에서는 사용자가 SharePlex 구성 파일을 완전히 이해하고 있다고 가정합니다. 지침에서는 중요한 구문 요소를 축약된 표현으로 사용합니다. 자세한 내용은 데이터 복제를 위해 SharePlex 구성를 참조하십시오.을 참조하십시오.

구문에 사용되는 규칙

이 항목의 구성 구문에서 자리 표시자는 다음을 나타냅니다.

  • source_specification[n]은 소스 객체(owner.object)의 정규화된 이름이거나 와일드카드 사양입니다.
  • target_specification[n]은 타겟 객체의 정규화된 이름이거나 와일드카드 사양입니다.
  • host는 SharePlex가 실행되는 시스템의 이름입니다. hostB와 같이 이름에 문자를 추가하여 다른 시스템을 식별합니다.
  • db는 데이터베이스 사양입니다. 데이터베이스 사양은 연결 유형에 따라 Oracle SID, TNS 별칭 또는 데이터베이스 이름 앞에 o. 또는 r.이 추가되는 것으로 구성됩니다. 타겟이 JMS, Kafka 또는 파일인 경우 데이터베이스 식별자가 필요하지 않습니다.

중요! 데이터 복제를 위해 SharePlex 구성을 참조하십시오.

배포 옵션

데이터를 단계화하려면 다음 옵션을 사용하면 됩니다.

  • 중간 시스템에 데이터베이스가 있는 경우 SharePlex를 구성하여 해당 데이터베이스에 게시한 다음, 데이터를 다시 캡처하여 하나 이상의 원격 타겟에 복제할 수 있습니다.

  • 중간 시스템에 데이터베이스가 없는 경우 SharePlex를 구성하여 데이터를 가져오고 큐에 넣은 다음, 하나 이상의 원격 타겟으로 익스포트할 수 있습니다. 시스템에 Capture 프로세스가 없습니다. 이를 패스스루 구성이라고 합니다. 소스 시스템에서 타겟 시스템으로 데이터를 직접 전달합니다.

중간 시스템에 게시하는 단계화

이 구성을 사용하려면 다음을 수행합니다.

  • SharePlex 데이터베이스 계정은 모든 시스템에 있어야 하며 모든 시스템에서 동일한 이름이어야 합니다. 이 계정은 일반적으로 SharePlex를 설치할 때 생성됩니다. 자세한 내용은 SharePlex 설치 안내서를 참조하십시오.
  • 트리거는 타겟 시스템뿐만 아니라 중간 데이터베이스에서도 비활성화되어야 합니다.

  • 중간 시스템의 Oracle 데이터베이스에서 타겟 시스템으로의 Oracle DDL 복제는 지원되지 않습니다. 소스 시스템에서 중간 시스템까지만 지원됩니다.

  • 두 개의 구성 파일을 생성합니다. 하나는 소스 시스템에, 다른 하나는 중간 시스템에 생성합니다.

  • Capture가 완료되기 전에 리두 로그가 래핑되는 경우 소스 시스템 및 중간 시스템에서 아카이브 로깅을 활성화합니다.

소스 시스템의 구성 옵션

이 구성은 소스 시스템에서 중간 시스템의 데이터베이스로 복제됩니다.

참고: 이 템플릿에서 hostB는 중간 시스템입니다.

datasource_specification

    
source_specification1 target_specification1 hostB@o.SID
source_specification2 target_specification2 hostB@o.SID
소스 시스템의 예
Datasource:o.oraA    
hr.emp hr.emp2 hostB@o.oraB
hr.sal hr.sal2 hostB@o.oraB
cust.% cust.% hostB@o.oraB

참고: 이와 동일한 구성에서는 중간 시스템을 통해 단계화되지 않고 다른 소스 객체의 데이터를 다른 타겟으로 직접 라우팅할 수 있습니다. 별도의 줄에 적절한 라우팅을 지정하면 됩니다.

중간 시스템의 구성 옵션

이 구성은 중간 시스템의 데이터베이스에서 데이터를 캡처한 다음, 이를 타겟 시스템에 복제합니다. 소스 구성에서 타겟 테이블이었던 테이블은 이 구성에서 소스 테이블입니다. 타겟은 지원되는 모든 SharePlex 타겟이 될 수 있습니다.

datasource_specification

    
source_specification1 target_specification1 hostC[@db][+...]
source_specification2 target_specification2 hostD[@db][+...]
중간 시스템의 예
Datasource:o.oraB    
hr.emp hr.emp2 hostC@o.oraC
hr.sal hr.sal2 hostD@o.oraD+hostE@r.mssE
cust.% cust.% !cust_partitions

참고: 이 예의 마지막 항목은 수평으로 파티셔닝된 복제를 사용하여 sales.accounts 테이블의 여러 데이터를 다양한 지역 데이터베이스에 배포하는 방법을 보여줍니다. 자세한 내용은 수평으로 파티셔닝된 복제 구성를 참조하십시오.

중간 시스템의 필수 매개변수 설정

(Oracle 중간 데이터베이스) 중간 데이터베이스가 Oracle인 경우 SP_OCT_REPLICATE_POSTER 매개변수를 1로 설정합니다. 이는 중간 시스템의 Capture 프로세스에 SharePlex에 의해 게시된 변경 사항을 캡처하고 이를 타겟 시스템에 복제하도록 지시합니다. (기본값은 0입니다. 이는 Capture가 동일한 시스템의 Post 활동을 무시한다는 의미입니다.)

sp_ctrl에서 다음 명령을 실행합니다. 변경 사항은 다음에 Capture가 시작될 때 적용됩니다.

set param SP_OCT_REPLICATE_POSTER 1

중간 시스템에서 패스스루로 단계화

이 구성을 사용하려면 다음을 수행합니다.

  • oratab 파일(Unix 및 Linux 시스템)에서 Oracle 인스턴스 및 ORACLE_SID 사양을 생성합니다. 데이터베이스는 비어 있을 수 있습니다.

  • DDL 복제는 지원되지 않습니다.

  • 소스 시스템에 하나의 구성 파일을 생성합니다.

소스 시스템의 구성 옵션

참고: 이 템플릿에서 hostB는 중간 시스템입니다.

datasource_specification

source_specification1 target_specification1 hostB*hostC[@db]
source_specification2 target_specification2 hostB*hostD[@db][+hostB*hostE[@db][+...]
source_specification3 target_specification3 hostB*hostX[@db]+hostY[@db]
  • hostB*host 구문은 패스스루 동작을 구성합니다.
  • 모든 데이터가 중간 시스템을 먼저 패스스루하는 복합 라우팅 맵을 사용하는 경우 각 타겟 경로에서 hostB* 구성 요소를 사용해야 합니다.
  • 또한 이 구성 파일의 세 번째 줄에서와 같이 소스 객체의 데이터가 한 타겟에 직접 복제되고 중간 시스템을 통해 다른 타겟에도 복제되는 복합 라우팅 맵을 사용할 수도 있습니다.
예
Datasource:o.oraA    
hr.emp hr.emp2 hostB*hostC@o.oraC
hr.emp hr."Emp_3" hostB*hostC@r.mssB
cust.% cust.% hostB*hostD@o.oraD+hostE@o.oraE

고가용성을 유지하도록 복제 구성

이 지침에서는 고가용성: 소스 데이터베이스의 미러인 보조 Oracle 데이터베이스에 복제를 목적으로 SharePlex를 설정하는 방법을 보여줍니다. 이 전략은 서로 반대인 두 개의 SharePlex 구성이 포함된 양방향 복제를 사용합니다. 보조(대기) 시스템의 구성은 기본 시스템이 실패할 경우 장애 조치를 준비하기 위해 중지된 해당 시스템의 Export 프로세스와 함께 활성화된 상태로 유지됩니다.

참고: CrunchyData 고가용성 클러스터 환경 설정에 대한 정보는 SharePlex 설치 및 설정 안내서의 PostgreSQL 고가용성 클러스터에 SharePlex 설치 섹션을 참조하십시오.

이 전략은 다음과 같은 비즈니스 요구 사항을 지원합니다.

  • 재해 복구
  • 유지 보수 주기 또는 기계적 오류가 발생하더라도 지속적으로 비즈니스 애플리케이션 운영

이 전략에서 SharePlex는 다음과 같이 작동합니다.

  • 일반적인 조건에서 SharePlex는 기본 데이터베이스의 변경 사항을 보조 데이터베이스에 복제합니다.
  • 기본 시스템 또는 데이터베이스가 오프라인 상태이고 사용자가 보조 시스템으로 전송되면 SharePlex는 변경 사항을 캡처하고 기본 시스템이 복원될 때까지 해당 시스템의 데이터를 큐에 넣습니다.
  • 기본 시스템이 복원되면 SharePlex는 해당 변경 사항으로 시스템을 업데이트한 다음, 기본 데이터베이스에서 캡처 및 복제를 재개합니다.

지원되는 소스

Oracle 및 PostgreSQL

지원되는 타겟

Oracle

기능

이 복제 전략은 명명된 익스포트 및 Post 큐의 사용을 지원합니다.

참고: 컬럼 매핑 및 파티셔닝된 복제는 고가용성 구성에 적합하지 않습니다. 소스 객체와 타겟 객체의 이름을 다르게 명명할 수 있지만 이로 인해 고가용성 구조의 관리가 더욱 복잡해집니다.

요구 사항

  • 지침에 따라 시스템을 준비하고, SharePlex를 설치하고, 데이터베이스 계정을 구성합니다(참조: SharePlex 설치 안내서).
  • 모든 객체는 두 시스템 모두에 전체적으로 있어야 합니다.
  • 타겟 객체는 소스 객체와 동일한 구조 및 정규화된 이름을 가져야 합니다.

  • 모든 시스템에서 아카이브 로깅을 활성화합니다.

  • SharePlex를 제외한 모든 사용자에 대한 INSERT, UPDATE 및 DELETE 작업을 거부하는 스크립트를 만듭니다.

장애 조치를 위해서는 다음이 필요합니다.

  • 기본 시스템에서 사용되는 애플리케이션을 보조 시스템에서 사용할 수 있도록 합니다.
  • 복제되지 않은 데이터베이스 객체와 인스턴스 외부의 중요 파일을 보조 시스템에 복사합니다.
  • 장애 조치 프로시저 중에 실행할 수 있는 INSERT, UPDATE 및 DELETE 권한을 모든 사용자에게 부여하는 스크립트를 만듭니다.
  • 장애 조치 프로시저 중에 사용할 보조 시스템의 제약 조건을 활성화하는 스크립트를 만듭니다.
  • 사용자를 보조 시스템으로 재배치하기 위한 장애 조치 프로시저를 개발합니다.

참고: Oracle 핫 백업을 사용하여 보조 인스턴스를 생성하는 경우 스크립트를 유지합니다. 스크립트를 수정하여 기본 인스턴스를 다시 생성할 수 있습니다.

구문에 사용되는 규칙

이 항목의 구성 구문에서 자리 표시자는 다음을 나타냅니다.

  • hostA는 기본 시스템입니다.

  • hostB는 보조 시스템입니다.
  • ownerA.object는 hostA에 있는 객체의 정규화된 이름이거나 와일드카드 사양입니다.
  • ownerB.object는 hostB에 있는 객체의 정규화된 이름이거나 와일드카드 사양입니다.
  • oraA는 hostA의 Oracle 인스턴스입니다.
  • oraB는 hostB의 Oracle 인스턴스입니다.

중요! 구성 파일의 구성 요소에 대한 자세한 내용은 데이터 복제를 위해 SharePlex 구성을 참조하십시오.

구성

고가용성 구성은 서로 반대인 두 가지 구성을 사용합니다. 데이터베이스의 모든 객체를 복제하려면 config.sql 스크립트를 사용하여 구성 프로세스를 간소화하면 됩니다. 자세한 내용은 SharePlex 참조 안내서의 구성 스크립트 섹션을 참조하십시오.

소스 시스템(기본 시스템)의 구성

Datasource:o.oraA

   
ownerA.object ownerB.object hostB@o.oraB

타겟 시스템(보조 시스템)의 구성

Datasource:o.oraB

   
ownerB.object ownerA.object hostA@o.oraA

장애 조치를 위한 시스템 준비

  1. 보조 시스템(처음에는 수동 시스템이 될 시스템)에서 sp_ctrl을 실행한 후 다음 명령을 실행하여 보조 시스템에서 Export 프로세스를 중지합니다. 그러면 보조 시스템에서 실수로 발생하는 일(예: 예약된 작업 변경 데이터)이 기본 시스템으로 다시 복제되지 않습니다. 이는 시스템 간 역할 전환이 필요할 때까지 해당 시스템에서 SharePlex의 필수 상태입니다.
  2. 초기 동기화 및 시작을 수행합니다. 이 프로시저 중에 소스 구성을 활성화합니다. 자세한 내용은 프로덕션 시스템에서 복제 시작를 참조하십시오.
  3. 보조 시스템에서 Export 프로세스가 중지되었는지 확인하고 해당 시스템에서 구성을 활성화합니다. 보조 시스템의 구성은 활성화된 상태로 유지되지만 Export 프로세스가 중지되고 사용자 활동이 부족하여 시스템이 정적 장애 조치 준비 상태로 유지됩니다.
  4. 보조 Oracle 인스턴스에 연결된 SharePlex 인스턴스를 모니터링하여 SharePlex가 아닌 DDL 또는 DML 변경 사항이 수행되지 않았는지 확인합니다. 다음과 같이 수행할 수 있습니다. sp_ctrl의 qstatus 명령을 사용하여 보조 시스템의 Export 큐 상태를 확인합니다. 시스템의 Capture 프로세스는 해당 시스템의 Post 프로세스를 무시하므로 큐는 비어 있어야 합니다. Export 큐에 메시지가 있는 경우, 해당 트랜잭션이 보조 시스템에서 시작되었거나 SP_OCT_REPLICATE_POSTER 매개변수가 실수로 활성화되었음을 의미합니다. SharePlex 명령 및 매개변수에 대한 자세한 내용은 SharePlex 참조 안내서를 참조하십시오.
  5. 복제 파일의 백업을 유지합니다.

복구 프로시저 수행

고가용성 환경에서 시스템에 오류가 발생하면 복제를 보조 시스템으로 이동한 다음, 복원 시 다시 기본 시스템으로 이동할 수 있습니다. 자세한 내용은 Oracle 장애 조치 후 복제 복구를 참조하십시오.

The document was helpful.

평가 결과 선택

I easily found the information I needed.

평가 결과 선택