이 항목에서는 SharePlex를 사용하여 복제할 Oracle 데이터베이스 객체의 특정 특성을 구성하는 방법에 대한 정보를 제공합니다.

행 고유성 보장

SharePlex에는 타겟에서 변경하는 행이 소스 행과 일치하는 올바른 행인지 확인하는 방법이 있어야 합니다. 이 방법은 키와 인덱스를 사용하여 일대일 관계를 보장함으로써 달성됩니다.

키의 역할

SharePlex는 복제되는 모든 소스 및 타겟 테이블, 특히 LONG 컬럼이 포함된 대형 테이블 및 여러 테이블에 기본 키 또는 유니크 키가 있는 경우 신속하게 작동합니다. 사용할 키를 선택할 때 SharePlex는 다음 우선순위에 따라 사용 가능한 가장 적합한 키 컬럼을 사용합니다.

• 기본 키
• 가장 적은 수의 컬럼이 있는 유니크 키(컬럼 중 하나 이상이 NULL이 아님)

• 컬럼 수가 가장 적은 유니크 키

최상의 성능을 위해서는 기본 및 유니크 키 추가 로깅을 활성화하는 것이 좋습니다.

테이블에 기본 키 또는 유니크 키가 없거나 Oracle이 SharePlex에 대해 잘못된 유니크 키를 기록하는 경우, 구성 파일을 생성할 때 키로 사용할 SharePlex 컬럼을 지정할 수 있습니다. 이는 키 정의라고 하며 구성 파일에 지정됩니다. 자세한 내용은 SharePlex 관리 안내서의 유니크 키 정의 를 참조하십시오.

키 정의의 또 다른 방법은 고유성을 설정하는 하나 이상의 컬럼을 기반으로 고유 인덱스를 생성하거나 사용하는 것입니다.

올바른 키가 기록되었는지 확인

기본 키 및 유니크 키 추가 로깅이 활성화되어 있고 테이블에 기본 키가 없는 경우 Oracle은 기록할 유니크 키 유형을 결정해야 합니다. 테이블에 여러 개의 유니크 키가 있는 경우 Oracle은 사용할 최상의 키를 결정하고 모든 UPDATE 프로세스에 대해 해당 컬럼 값을 기록합니다. 테이블에 어떤 유형의 키도 없으면 Oracle은 LONG 또는 LOB를 제외한 모든 컬럼을 기록합니다.

SharePlex는 데이터 복제에 사용할 키도 식별해야 합니다. Oracle과 마찬가지로 SharePlex는 다음 순서로 키를 선택합니다.

• 기본 키(있는 경우)
• 최상의(또는 유일한) 유니크 키(있는 경우)
• 모든 컬럼

SharePlex에 의해 복제되는 테이블에 기본 키가 없지만 여러 개의 유니크 키가 있는 경우, Oracle이 기록하는 키 컬럼이 SharePlex에 필요한 컬럼이 아닐 수 있습니다.

키 또는 고유 인덱스가 없는 테이블

SharePlex가 테이블에서 키 또는 고유 인덱스를 감지할 수 없는 경우 LONG 및 LOB를 제외한 모든 컬럼을 사용하여 키를 구성합니다. 이 키는 내부적으로 유지 관리되며 테이블 자체에는 생성되지 않습니다.

이 결과에 따른 WHERE 절로 인해 Oracle이 타겟 테이블에서 전체 테이블 검사를 수행하여 행을 찾고 이로 인해 복제 속도가 크게 느려지므로 이는 바람직한 옵션이 아닙니다. 또한 행 고유성을 적용할 수 없습니다.

예를 들어 여러 행에서 LONG이 아닌 컬럼에 동일한 값이 포함될 수 있지만 LONG 컬럼이 여러 값을 가질 가능성이 있는 경우 테이블은 사용자 또는 SharePlex에 의해 감지되지 않고 동기화되지 않을 수 있습니다. 다음 예에서는 문제를 보여줍니다. 테이블의 행은 LONG 컬럼을 제외하고 동일하며, 기본 키나 유니크 키가 없습니다.

소스 시스템의 사용자가 첫 번째 행에서 A 컬럼을 15로 변경했다고 가정합니다. 타겟 테이블에 변경 사항을 적용하기 위해 SQL 문을 구성할 때 SharePlex는 A 컬럼과 B 컬럼(UPDATE tablename SET A 컬럼을 15로, 여기서 A 컬럼 = 10 및 B 컬럼 = 20)을 사용해 키를 생성하여 변경할 행을 찾습니다. 이 기준을 충족하는 행이 3개 있으므로 SharePlex가 잘못된 행에 변경 사항을 게시할 수 있습니다.

null이 포함된 키

키가 NULL을 허용하는 경우 SharePlex는 UPDATE 및 DELETE에 대한 행의 고유성을 보장할 수 없으므로 타겟 시스템에서 잘못된 행을 변경할 가능성이 있습니다. SharePlex가 NULL을 허용하는 키를 처리하는 방법을 제어하려면 SP_SYS_IN_SYNC 매개변수를 설정합니다. 자세한 내용은 SharePlex 참조 안내서를 참조하십시오.

키 값의 변경 사항

SharePlex는 특별한 설정 없이 키 컬럼 값의 변경 사항을 처리합니다. 그러나 키에 시퀀스가 사용되고 해당 값이 업데이트될 가능성이 있는 경우 업데이트로 인해 타겟 시스템에서 키가 중복되지 않도록 시퀀스를 만듭니다. 업데이트될 가능성이 없으면 새 값을 사용하여 작업을 적용하고, 해당 값이 이미 타겟 테이블의 다른 행에 키로 존재하는 경우 SharePlex는 유니크 키 제약 조건 위반 및 동기화 중단 오류를 반환합니다. 이 오류 유형은 “x + n” 공식을 사용하여 값을 업데이트할 때 발생할 수 있습니다. 여기서 n은 증분 증가입니다. “x + n” 값 중 하나가 기존 값과 같을 수 있습니다.

다음은 키 컬럼의 값이 1씩 증가하는 예입니다.

Key_Col

1

4

5

7

SQL> update table X set a=a+1; commit

새 값은 다음과 같으며 타겟 시스템에 복제됩니다.

Key_Col

2

5

6

8

SharePlex는 작업이 리두 로그에 입력되는 순서대로 업데이트를 수행합니다.

update x set a=2 where a=1;(성공)

update x set a=5 where a=4;(5 값이 이미 존재하므로 실패)

update x set a=6 where a=5;(성공)

update x set a=8 where a=7;(성공)

Post가 타겟 시퀀스에 사용하는 사전 이미지 값은 소스에서 복제된 증가된 값과 동일합니다. Oracle은 고유 제약 조건 위반으로 인해 작업을 거부합니다. 또 다른 예는 A를 B로 업데이트한 다음, B를 C로 업데이트하는 트랜잭션입니다.

중요! 피어-투-피어 복제를 사용하려는 경우 키에 대한 추가 요구 사항이 있습니다. 자세한 내용은 SharePlex 관리 안내서의 여러 피어 데이터베이스를 유지 관리하도록 복제 구성을 참조하십시오.

인덱스

복제 환경에서는 인덱스를 올바르게 사용해야 합니다. 인덱스는 타겟 데이터의 무결성을 유지합니다.

• 고유 인덱스가 있는 소스 테이블을 복제하는 경우 타겟 테이블에도 고유 인덱스가 있어야 합니다.
• 모든 대형 테이블에는 타겟 시스템에 고유 인덱스가 있어야 합니다. 고유 인덱스가 없으면 Oracle은 Post에 의해 변경될 행을 찾기 위해 전체 테이블을 검사합니다.
• 일부 애플리케이션은 기본 키 제약 조건을 사용하지 않으므로 기본적으로 고유 인덱스가 생성되지 않습니다. 그러나 종종 고유 인덱스(CREATE UNIQUE INDEX 명령을 사용하지 않음)로 생성되었고 개인 이름, 직원 식별 번호 등 고유한 값으로 채워진 하나 이상의 컬럼에서 생성되었더라도 이름이 지정되지 않은 인덱스가 있습니다. 테이블에 대한 고유 인덱스가 없으면 구성 파일을 생성할 때 고유 인덱스를 생성하거나 사용자 정의 키를 지정하는 것이 좋습니다. 자세한 내용은 SharePlex 관리 안내서의 유니크 키 정의 섹션을 참조하십시오.
• 고유 인덱스를 식별하거나 생성한 후에는 SharePlex의 힌트 기능을 사용하여 Oracle이 해당 인덱스를 사용하는지 확인할 수 있습니다. 자세한 내용은 SharePlex 관리 안내서의 Oracle 인덱스 힌트 사용 섹션을 참조하십시오.

• 테이블에 외래 키가 있는 경우 외래 키에 대한 수정으로 인해 전체 테이블 검사가 발생하지 않도록 적절한 컬럼이 인덱싱되었는지 확인합니다.

• 인덱스를 최신 상태로 유지하지 않으면 Post 프로세스 속도가 저하될 수 있습니다. 조각화된 항목을 다시 빌드합니다.

타겟 테이블에 인덱스가 너무 많으면 행이 추가되고 삭제될 때 Oracle은 해당 인덱스를 모두 업데이트해야 합니다. 이로 인해 복제를 포함한 전체 시스템 속도가 느려집니다. 가장 유용성이 높은 인덱스로 인덱스 수를 제한하는 것이 좋습니다.

대부분 한 가지 유형의 DML을 수행하는 애플리케이션의 경우 다음을 고려합니다.

• INSERT: 몇 개의 인덱스만 사용하여 유지 보수를 제한합니다.
• UPDATE: INSERT 문 이후에 변경되지 않는 컬럼에 인덱스를 사용합니다.
• DELETE: 가능한 한 많은 인덱스를 제거합니다.

수백만 건의 SQL 작업을 수행하는 대규모 일괄 작업을 실행하는 경우, 일괄 작업 전에 불필요한 인덱스를 제거한 후 마지막에 다시 빌드합니다. 이렇게 하면 SharePlex 실행이 더 빨라지고 나중에 더 체계화된 인덱스를 갖게 됩니다.

비트맵 인덱스

성능을 위해 Post 프로세스가 데이터를 적용하는 동안에는 비트맵 인덱스를 사용하지 마십시오. 이러한 인덱스는 Post 프로세스의 성능에 부정적인 영향을 미칠 수 있습니다.

타겟 테이블에서 비트맵 인덱스를 사용해야 하는 경우 Post에서 적용되는 트랜잭션에 미치는 영향과 쿼리에 대한 이점을 비교합니다.

• Oracle은 비트맵 항목을 추가, 업데이트 또는 삭제할 때 비트맵 세그먼트와 연관된 모든 행을 효과적으로 잠급니다.
• 비트맵 세그먼트에는 수백 개의 행에 대한 참조가 포함될 수 있습니다. 결과적으로 서로 다른 Post 세션(소스 시스템의 모든 세션에 Post 세션이 있음)에서 변경한 내용은 해당 작업이 동일한 비트맵 세그먼트의 비트맵 항목을 업데이트하는 경우 서로를 차단할 수 있습니다.
• 계속 진행하려면 Post가 차단을 감지하고 해결해야 하며, 이로 인해 잠금 수가 많은 경우 게시가 크게 지연됩니다.
• 일반적으로 여러 동시 세션에서 비트맵 인덱스가 있는 테이블에 자주 삽입하면 잠금 충돌이 발생하지만 해당 테이블에 대한 임의 업데이트 및 삭제 활동은 발생하지 않습니다. SharePlex는 보다 정적인 테이블에 비트맵 인덱스를 두라는 Oracle 권장 사항을 따릅니다.

참고: 비트맵 인덱스 복제는 권장되지 않습니다. 비트맵 인덱스가 있는 테이블을 변경할 때마다 인덱스가 다시 빌드됩니다. 다시 빌드와 관련된 비용(Oracle 시간 및 리소스)이 SQL UPDATE 문에 추가됩니다.

타겟에서의 트리거 실행 방지

소스 시스템에서 실행된 트리거로 인한 DML 변경 사항은 리두 로그에 입력되고 SharePlex에 의해 타겟 데이터베이스에 복제됩니다. 그 결과, 동일한 트리거가 타겟 시스템에서 실행되고 동일한 DML 변경(복제를 통해 이미 수행됨)을 시작하면 동기화 중단 오류가 발생합니다.

예를 들어 소스 시스템에서 TableA에 대한 INSERT가 TableB에 대한 INSERT를 트리거하는 경우 SharePlex는 두 INSERT를 타겟 시스템에 복제합니다. Post 프로세스는 타겟 시스템의 TableA에 첫 번째 INSERT를 적용하여 TableB에 대한 INSERT를 트리거합니다. 따라서 Post가 복제된 INSERT를 TableB에 게시하려고 시도하면 유니크 키 위반이 발생합니다. TableA에 대해 트리거가 실행되었기 때문에 행이 이미 존재합니다.

트리거는 복제 전략에 따라 다음과 같이 처리될 수 있습니다.

복제 구성에 없는 객체에 대한 트리거는 활성 상태로 유지될 수 있습니다.

트리거 스크립트 사용 방법에 대한 중요한 정보는 SharePlex 참조 안내서를 참조하십시오.

무결성 제약 조건 구성

무결성 제약 조건은 복제에 영향을 미칩니다. 해당 제약 조건을 처리하려면 이러한 가이드라인을 따릅니다.

외래 키 제약 조건

타겟 테이블에서는 외래 키 제약 조건을 비활성화해야 합니다. SharePlex는 소스 외래 키 제약 조건의 결과를 복제합니다. 소스 외래 키 결과의 정확한 복제를 위해서는 서로 외래 키가 있는 테이블이 복제 구성에 모두 포함되어야 합니다. 참조 제약 조건이 있는 모든 테이블은 타겟 데이터베이스에 있어야 합니다. 하나 이상을 생략하면 참조 무결성이 손상될 수 있습니다.

참고: 타겟 테이블에서 제약 조건이 지연된 경우 Post 트랜잭션이 제약 조건 유효성 검사에 실패할 수 있습니다. 이 문제를 해결하려면 트랜잭션이 성공할 수 있도록 SP_OPO_DISABLE_OBJNUM 매개변수를 활성화합니다. 기본 타겟 테이블은 재동기화될 때까지 동기화 중단 상태가 계속 유지됩니다.

ON DELETE CASCADE 제약 조건

SharePlex는 ON DELETE CASCADE 제약 조건이 타겟 테이블에서 활성화된 상태로 유지할 수 있는 기능을 제공하지만 매개변수 설정을 통해 명시적으로 활성화해야 합니다. Post는 ON DELETE CASCADE 종속성을 감지하고 복제된 단계화 삭제가 하위 테이블에 게시되는 것을 금지합니다.

SharePlex를 통해 이 지원을 활성화하지 않는 경우 타겟에서 이러한 제약 조건을 수동으로 비활성화해야 합니다. 비활성화하지 않으면 SharePlex는 기본 삭제와 단계화 삭제를 모두 복제하므로 타겟에서 단계화 삭제가 수행될 때 충돌과 오류가 발생합니다.

ON DELETE CASCADE 지원을 활성화하려면 다음을 수행합니다.

1. 소스에서 기본 키, 고유 인덱스 컬럼 및 외래 키 컬럼의 로깅을 활성화합니다.

2. 다음 SharePlex 매개변수를 설정합니다.

   • SP_OPO_DEPENDENCY_CHECK 매개변수를 2로 설정
   • SP_OCT_REDUCED_KEY 매개변수를 0으로 설정
   • SP_OCT_REDUCED_KEY 매개변수를 0, 1 또는 2로 설정

참고: 피어-투-피어 복제에서는 SP_OPO_REDUCED_KEY를 0으로 설정해야 합니다.

체크 제약 조건

타겟 시스템에서 체크 제약 조건을 비활성화합니다. 체크 제약 조건을 불필요한 오버헤드를 추가합니다. 이러한 검사는 소스 시스템에서 충족되기 때문에 효과적으로 관리되고 동기화된 복제 환경에서 중복됩니다. 고가용성을 위해 장애 조치 프로시저의 일부로 제약 조건을 다시 활성화하는 스크립트를 빌드할 수 있습니다.

타겟 객체에 대한 접근 방지

피어-투-피어 복제를 제외한 모든 시나리오에서 SharePlex 데이터베이스 사용자는 타겟 객체에서 DML 또는 DDL을 수행할 수 있는 유일한 사용자여야 합니다. 다른 개인, 작업 또는 애플리케이션이 타겟 객체에 대해 DML 또는 DDL을 변경하는 경우 타겟 데이터에 소스 시스템의 데이터 상태가 더 이상 반영되지 않을 수 있습니다. 자세한 내용은 SharePlex 관리 안내서의 동기화 개념 이해 섹션을 참조하십시오.

시퀀스 구성

SharePlex는 ALTER SEQUENCE 및 DROP SEQUENCE 명령과 DML 트랜잭션 중에 수행된 Oracle 시퀀스에 대한 변경 사항을 복제합니다. 특정 복제 전략에서는 시퀀스를 복제할 필요가 없을 수도 있습니다.

• 고가용성: 예

  사용자는 SharePlex가 시퀀스를 복제하는 방식을 통해 시퀀스를 증분하거나 재사용하는 것에 대해 우려하지 않고도 장애 조치 데이터베이스를 즉시 사용할 수 있습니다.

• 보고, 데이터 공유, 기타 기본적인 단방향 복제: 아니요

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

• 피어-투-피어: 아니요

  SharePlex는 동일한 시퀀스의 피어-투-피어 복제를 지원하지 않습니다. 자세한 내용은 SharePlex 관리 안내서의 여러 피어 데이터베이스를 유지 관리하도록 복제 구성을 참조하십시오.

복제 시퀀스를 구성하려면 다음을 수행합니다.

1. 시퀀스를 복제하려면 기본 키와 유니크 키의 추가 로깅을 데이터베이스 수준에서 활성화하거나 sys.seq$ 테이블에서 기본 키에 대한 추가 로깅을 활성화해야 합니다.

2. 캐싱을 사용하고 캐시를 최소 20씩 증가하도록 설정합니다. 시퀀스가 캐시되면 SharePlex는 값을 그룹으로 복제할 수 있습니다. 시퀀스가 캐시되지 않으면 시퀀스에서 값을 얻을 때마다 SharePlex가 디스크로 이동해야 하므로 더 중요한 데이터의 복제 속도가 느려집니다.

3. 타겟 시스템에서 시퀀스의 고유성을 보장하려면 타겟 시퀀스의 시작 값이 소스 시퀀스의 시작 값보다 커야 합니다. 다음 공식을 사용하여 타겟 START_WITH 값을 결정합니다.

   source_current_value+ (source_INCREMENT_BY_value x source_CACHE_value) =target_START_WITH_value

   중요! (source_INCREMENT_BY_value x source_CACHE_value)는 2GB를 초과하면 안 됩니다. 초과하면 시퀀스 복제가 실패합니다.

4. 테이블과 마찬가지로 구성에서 소유자 및 이름별로 시퀀스를 지정합니다.

5. 시퀀스 변경 사항은 DDL 명령이기 때문에 Post 프로세스는 시퀀스 업데이트가 완료될 때까지 모든 게시를 일시 중지합니다. 이러한 이유로 특히 시퀀스가 캐시되지 않은 경우에는 테이블과 별도의 Post 큐를 통해 시퀀스를 처리하는 것이 좋습니다. 자세한 내용은 SharePlex 관리 안내서의 데이터를 복제하도록 SharePlex 구성 섹션을 참조하십시오.

SharePlex는 ALTER SEQUENCE 명령을 사용하여 다음과 같이 타겟 데이터베이스의 시퀀스를 업데이트합니다.

• 증분 값을 다음으로 변경합니다.

  source_INCREMENT_BY_valuexsource_CACHE_value

• NOCACHE로 설정합니다.
• 시퀀스에 대해 UPDATE를 수행합니다.

• 다음 값을 설정하여 시퀀스를 다시 변경합니다.

  Increment_value=source_INCREMENT_BY_value

  Cache_value=source_CACHE_value

SharePlex는 리두 로그 레코드가 두 작업을 구별하지 않기 때문에 ALTER SEQUENCE 작업을 시퀀스에 대한 간단한 SELECT(UPDATE)처럼 처리합니다.