SharePlex 11.4 - 설치 및 설정 안내서

SharePlex를 지원하도록 Oracle 로깅 설정

SharePlex를 지원하도록 Oracle 로깅 설정

SharePlex는 온라인 및 아카이브된 Oracle 리두 로그에서 캡처합니다. SharePlex는 raw device, 파일 시스템 장치 및 ASM 인스턴스에 저장되는 리두 로그 및 데이터 파일을 지원합니다.

아카이브 로깅 활성화

복제가 활성화된 동안 Capture 프로세스가 중지되는 경우(또는 SharePlex 사용자가 중지한 경우) Capture는 리두 로그에 해당 위치를 기록하고 다시 시작될 때 해당 지점부터 계속됩니다. 그러나 다음 상태가 발생하는 경우 Capture는 리두 로그 대신 아카이브 로그를 읽어야 할 수도 있습니다.

• Capture가 중지되고 다시 시작되는 시점 사이에는 긴 지연이 있으며 해당 시간 동안 리두 로그가 래핑됩니다. 아카이브 로그를 사용할 수 있는 경우 Capture는 이를 읽고 누락된 레코드를 찾습니다.
• Capture는 Oracle 트랜잭션 활동 속도를 늦추고 Capture가 Oracle을 따라잡기 전에 리두 로그가 래핑됩니다.

온라인 로그를 사용할 수 없을 때 중단 없는 캡처를 지원하려면 소스 시스템에서 및 SharePlex가 데이터를 캡처할 다른 시스템(예: 단계화 복제 전략의 중간 시스템)에서 아카이브 로깅을 활성화해야 합니다. 활성화하지 않으면 Capture가 처리를 완료하기 전에 온라인 로그가 래핑되는 경우 소스 및 타겟 데이터를 재동기화해야 합니다.

Capture 문제를 방지하려면 더 빠르고 중단 없는 복제를 지원하도록 다음과 같이 아카이브 로깅을 구성합니다.

온라인 로그 구성

이상적으로는 SharePlex가 아카이브 로그를 읽지 않도록 리두 로그를 구성해야 합니다. 대부분의 경우 온라인 로그를 읽는 것이 아카이브를 읽는 것보다 빠릅니다. 온라인 리두 로그가 아카이브 로그의 처리를 최소화할 수 있을 만큼 크고 많아야 합니다. 최소한 몇 시간 분량의 데이터를 래핑하지 않고도 보관할 수 있을 만큼 리두 로그 용량이 있어야 합니다.

적절한 온라인 로그 구성을 테스트하려면 다음을 수행합니다.

사전 프로덕션 테스트에서 다음을 수행하여 Capture가 아카이브 로그를 읽는지 확인할 수 있습니다.

1. SHAREPLEX_ACTID 테이블을 쿼리하여 SharePlex가 처리 중인 로그를 확인합니다.

   SQL> select seqno from splex.shareplex_actid

2. Oracle의 V$LOG 테이블을 쿼리하여 Oracle이 작성하는 로그를 확인합니다.

   SQL> select sequence# from v$log where status='CURRENT'

3. sequence# 값에서 seqno 값을 뺍니다. 이는 Oracle에 비해 Capture 로그가 얼마나 지연되는지를 보여줍니다.
4. 해당 값에서 온라인 리두 로그 수를 뺍니다. 숫자가 음수인 경우 SharePlex는 아카이브 로그를 처리하는 것입니다. 예를 들어 10개의 리두 로그가 있고 가 11개가 지연되는 경우 SharePlex는 아카이브 로그를 처리하는 것입니다. 그런 다음, 이 결과를 사용하여 온라인 로깅 구성을 조정할 수 있습니다.

중요: Oracle이 리두 볼륨을 생성하는 속도보다 Capture가 느린 경우 다음 사항이 적용될 수 있습니다.

• SharePlex가 아카이브 로그에서 캡처하여 패리티를 복원할 때까지 기다리는 대신 데이터를 재동기화하는 것이 더 실용적일 수 있습니다.
• Capture가 누락된 작업을 처리하고 큐에 추가하는 동안 소스 시스템의 디스크 공간이 부족해질 수 있습니다.
• 특히 필요한 아카이브 로그를 더 이상 사용할 수 없는 경우 Post가 SQL 문을 구성하는 데 필요한 정보를 SharePlex로 인해 손실할 가능성이 있습니다. SharePlex가 실행되는 동안 항상 디스크 공간과 지연 시간을 모니터링하십시오.

적절한 로깅 수준 설정

• SharePlex 복제 구성을 활성화하기 전에 최소한의 추가 로깅을 설정해야 합니다.

• 최소한의 추가 로깅 외에도 기본 키와 유니크 키 추가 로깅을 모두 활성화하거나, 복제 중인 모든 테이블의 고유 컬럼에 추가 로그 그룹을 생성하는 것이 좋습니다. 행 업데이트에 대한 키 컬럼 값이 리두 로그에 있는 경우 SharePlex는 데이터베이스에서 해당 값을 가져올 필요가 없습니다. 사용량이 많은 시스템에서는 Read 프로세스의 성능이 크게 향상됩니다. 일부 SharePlex 기능을 사용하려면 기본 키 및 유니크 키 로깅을 활성화해야 합니다.

  참고: 복제 중인 테이블의 기본 키 또는 유니크 키가 기록되지 않는 경우 테이블의 rowid를 변경하는 ALTER TABLE DDL 명령은 후속 DML 작업에 영향을 미칠 수 있습니다. 키가 기록되지 않으면 SharePlex는 rowid를 기반으로 해당 값을 가져옵니다. ALTER TABLE...MOVE와 같이 rowid를 변경하는 작업으로 인해 후속 DML 작업에 잘못된 키 값이 사용될 수 있습니다.

• 테이블에 대해 수직으로 파티셔닝된 복제를 사용하는 경우 테이블 수준 로깅을 사용하여 복제할 컬럼과 외래 키와 같이 참조할 수 있는 다른 컬럼만 기록할 수 있습니다. 동일한 테이블에 대해 수평으로 파티셔닝된 복제를 사용하는 경우 필터로 지정한 컬럼을 기록해야 합니다.

복제를 위한 Oracle 데이터베이스 객체 설정

이 항목에서는 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)처럼 처리합니다.

SharePlex를 지원하도록 Oracle 데이터베이스 설정

SharePlex를 지원하도록 Oracle 데이터베이스 설정

특정 Oracle 데이터베이스 설정은 복제에 영향을 미치므로 적절하게 설정해야 합니다.

Post 커서를 지원하도록 OPEN_CURSORS 조정

SharePlex는 타겟 데이터베이스에서 Oracle OPEN_CURSORS 매개변수 값을 올바르게 설정해야 합니다. OPEN_CURSORS 값을 보려면 다음 SQL 문을 사용하여 데이터베이스를 쿼리합니다.

select value from V$PARAMETER where name = 'open_cursors';

Post 프로세스는 완료 후 닫히는 루틴 호출을 위해 10개의 커서를 예약하고 SQL 캐시 기능이 활성화된(기본값) 경우 트랜잭션당 최소 50개의 커서를 예약합니다. 자세한 내용은 SharePlex 관리 안내서의 SQL 캐싱 조정

SQL 캐싱을 비활성화하려는 경우 애플리케이션이 생성하는 최대 동시 업데이트 트랜잭션(세션) 수를 추정하고 다음 공식을 따릅니다.

10 + (최대 동시 트랜잭션 수 x 2) = 필요한 최소 열린 커서

OPEN_CURSORS 값이 없으면 수정하거나 추가할 수 있습니다. Oracle 매개변수를 변경하기 전에 Oracle 문서를 참조하십시오.

연결을 지원하도록 PROCESSES 매개변수 조정

PROCESSES 및 SESSIONS 매개변수의 경우 65는 현재 트랜잭션 볼륨을 처리하기 위해 타겟 데이터베이스에 대한 충분한 SQL 연결을 열 수 있도록 SharePlex Post 프로세스에 필요한 최소값입니다. 이 값은 SP_OPO_THREADS_MAX 매개변수의 기본 설정과 기본 Post 스레드에 대해 1을 더해 결정됩니다.

init.ora 파일의 PROCESSES 매개변수는 SharePlex 및 데이터베이스 사용자가 생성한 연결을 수용하도록 설정되어야 합니다. 해당 값은 데이터베이스가 소스 데이터베이스인지, 타겟 데이터베이스인지, 아니면 소스 데이터베이스와 타겟 데이터베이스 역할을 모두 수행하는 것인지에 따라 달라집니다.

데이터베이스를 소스로만 사용

데이터베이스가 소스로만 사용되는 경우 다음 공식은 Read 프로세스에서 수행된 로그인을 고려합니다.

(소스 데이터베이스 세션의 최대 수) + (백그라운드 Oracle 프로세스) + (SP_ORD_LDA_ARRAY_SIZE 매개변수의 값 +3) = PROCESSES에 대한 설정

데이터베이스를 타겟으로만 사용

Post 프로세스는 트랜잭션 일관성을 유지하기 위해 소스 시스템에 있는 세션 수만큼 타겟 시스템에 많은 연결을 생성합니다.

타겟 시스템의 PROCESSES 매개변수는 모든 연결과 다음을 수용할 수 있을 만큼 충분히 높게 설정되어야 합니다.

• 연결을 생성하는 백그라운드 Oracle 프로세스
• 쿼리를 위해 타겟 데이터베이스에 접근할 것으로 예상되는 최대 사용자 수

다음 공식을 지침으로 사용합니다.

(소스 데이터베이스 세션의 최대 수) + (타겟 데이터베이스 세션의 최대 수) + (백그라운드 Oracle 프로세스) = PROCESSES에 대한 설정

데이터베이스를 소스이자 타겟으로 사용

데이터베이스가 소스와 타겟 둘 다의 역할을 하는 경우 다음 공식은 다음을 통해 이루어진 연결을 고려합니다.

• Read 프로세스
• Post 프로세스
• 백그라운드 Oracle 프로세스
• 사용자 연결

(소스 데이터베이스 세션의 최대 수) + (타겟 데이터베이스 세션의 최대 수) + (백그라운드 Oracle 프로세스) + (SP_ORD_LDA_ARRAY_SIZE 매개변수 값 +3) = PROCESSES에 대한 설정

게시 개선을 위해 로그 버퍼 크기 조정

데이터베이스 작성자 수는 특히 동시 트랜잭션이 많은 경우 복제에 영향을 미칩니다. 트랜잭션이 커밋될 때마다 버퍼링된 데이터가 디스크로 플러시됩니다. 대부분의 트랜잭션은 작지만 버퍼가 큰 경우 게시 속도가 느려질 수 있습니다. 큰 트랜잭션이 커밋되고 더 일반적인 크기의 다른 트랜잭션이 커밋되면 두 번째 COMMIT은 전체 버퍼가 디스크에 플러시되는 동안 기다려야 합니다.

디스크에 플러시되는 버퍼의 크기를 줄이면 Post 프로세스 속도를 향상할 수 있습니다. 로그 버퍼 크기를 1024KB(또는 가능한 경우 512KB)로 줄여보십시오.

사용자 볼륨에 따라 SharePlex 트랜잭션 테이블 조정

SharePlex 타겟 데이터베이스에 대한 읽기 일관성을 유지하기 위해 SHAREPLEX_TRANS 테이블을 업데이트합니다. 복제 성능을 향상하고 해당 테이블의 경합을 줄이려면 이 테이블의 initrans 설정을 조정해야 할 수 있습니다.

• 프로덕션 데이터베이스의 동시 사용자가 500~1,000명인 경우 initrans가 30이 되도록 SHAREPLEX_TRANS 테이블을 다시 빌드합니다.
• 프로덕션 데이터베이스의 동시 사용자가 1,000명을 초과하는 경우 initrans 값이 40이 되도록 SHAREPLEX_TRANS 테이블을 다시 빌드합니다.

캐릭터셋의 변환 제어

이 항목에서는 SharePlex가 Oracle 소스와 타겟 간, Oracle 소스와 non-Oracle 타겟 간 캐릭터셋 변환을 처리하는 방법에 대해 설명합니다.

Oracle 소스와 Oracle 타겟 간의 복제

사용 중인 Oracle 캐릭터셋 내의 모든 문자를 SharePlex가 복제하도록 하려면 다음 중 하나가 충족되어야 합니다.

• 캐릭터셋은 소스와 타겟에서 동일합니다.
• 소스 데이터베이스 캐릭터셋은 타겟 데이터베이스 캐릭터셋의 하위 집합입니다(소스에 포함된 모든 문자는 타겟의 캐릭터셋에 있음).

SharePlex에 대해 테스트되고 지원되는 캐릭터셋은 다음과 같습니다.

US7ASCII

UTF8

WE8ISO8859P1

AL16UTF16

AL32UTF8

KO16KSC5601

기본적으로 SharePlex를 사용하면 Oracle 타겟 데이터베이스가 문자 변환을 수행할 수 있습니다. Post는 소스 데이터의 문자 인코딩을 Oracle에 알리고 Oracle은 필요한 변환을 수행합니다.

관련된 캐릭터셋에 따라 Oracle 변환으로 인해 데이터가 손실될 수 있습니다. 예를 들면 다음과 같습니다.

예 1: JA16SJIS 캐릭터셋에서 '쌀'에 대한 일본어 문자는 US7ASCII 캐릭터셋에 해당 기호가 없습니다. 이 기호를 US7ASCII 데이터베이스에 복제하려고 하면 Oracle은 이를 '?' 문자로 변환합니다.

예 2: Oracle에 따르면 WE8ISO8859P1 캐릭터셋은 US7ASCII 캐릭터셋의 상위 집합이므로 US7ASCII의 문자가 WE8ISO8859P1 타겟 데이터베이스에 변환되지 않은 상태로 게시된다고 가정하는 것이 논리적입니다. 이는 0x00에서 0x7F 범위의 문자에 해당됩니다. 그러나 Oracle은 0x80에서 0xFF 범위의 문자 중 최상위 비트를 제거합니다. 이 "변환"은 소스의 상위 집합인 캐릭터셋으로 복제하는 동안 데이터 손실을 초래할 수 있습니다.

참고: Oracle은 캐릭터셋이 동일한 경우 문자를 변환하지 않습니다. 따라서 WE8ISO8859P1 캐릭터셋이 있는 데이터베이스에 WE8ISO8859P1 데이터를 게시하면 Oracle 변환 프로세스가 무시됩니다.

변환하지 않고 데이터를 적용하려면 다음을 수행합니다.

변환과 함께 데이터를 적용하려면 SP_OPO_NLS_CONVERSION 매개변수를 1로 설정합니다.

참고: SharePlex는 소스 데이터베이스의 NLS_NCHAR_CHARACTERSET가 타겟 데이터베이스의 NLS_NCHAR_CHARACTERSET와 동일하지 않은 경우 항상 NVARCHAR 및 NCLOB 데이터를 변환합니다.

Oracle 소스와 non-Oracle 타겟 간의 복제

Open Target(non-Oracle) 타겟에 복제할 때 SharePlex는 Oracle 유니코드 캐릭터셋 및 US7ASCII 캐릭터셋으로부터의 복제를 지원합니다. SharePlex는 유니코드 캐릭터셋으로 Open Target에 데이터를 게시하므로 소스 데이터가 유니코드 또는 US7ASCII인 경우 타겟에서 변환이 필요하지 않습니다.

그러나 다음 사항이 true인 경우 타겟에서 변환이 필요합니다.

• 소스 데이터의 캐릭터셋이 Oracle 유니코드 또는 US7ASCII가 아닌 경우, 타겟에 게시하기 위해 유니코드로 변환을 수행하려면 타겟에 Oracle 클라이언트를 설치해야 합니다.
• 데이터가 유니코드 이외의 캐릭터셋으로 타겟 데이터베이스에 게시되어야 하는 경우 타겟에 Oracle 클라이언트를 설치하여 변환을 수행하고 타겟 명령을 사용하여 Post가 사용할 타겟 캐릭터셋을 식별해야 합니다.
• LOB 데이터를 복제하는 경우 소스 캐릭터셋이 무엇인지에 관계없이 변환이 필요합니다.

Linux에서 Oracle 클라이언트를 사용하여 변환을 수행하려면 다음을 수행합니다.

1. 타겟 시스템에 Oracle 관리자 클라이언트를 설치합니다. 클라이언트는 관리자 설치 유형이어야 합니다. Instant Client 및 Runtime 설치 유형은 지원되지 않습니다.
2. ORACLE_HOME을 클라이언트 설치로 설정합니다. ORACLE_SID를 별칭이나 존재하지 않는 SID로 설정합니다. SharePlex는 이를 사용하지 않으므로 데이터베이스가 실행 중일 필요가 없습니다.
3. 운영 체제에 맞는 Linux/Unix 설치 프로그램을 사용하여 SharePlex 설치 합니다.
4. SP_OPX_NLS_CONVERSION 매개변수가 기본값인 1로 설정되어 있어야 합니다.

변환 없이 유니코드 및 US7ASCII 데이터를 적용하려면 다음을 수행합니다.

소스 데이터가 유니코드 또는 US7ASCII이고 LOB 데이터를 복제하지 않는 경우 변환이나 Oracle 클라이언트가 필요하지 않습니다. SP_OPX_NLS_CONVERSION 매개변수를 0으로 설정하여 변환을 비활성화한 후 실행 중인 경우 Post를 재시작합니다.

Oracle 데이터를 지원하도록 SharePlex 설정

Oracle 데이터를 지원하도록 SharePlex 설정

이 항목에는 특정 Oracle 데이터 유형에 적용되는 설정 가이드라인이 포함되어 있습니다. 복제를 처음 시작하기 전에 이러한 가이드라인을 확인해야 합니다.

LOBs, LONGs, VARRAYs 및 XML

• LOB 또는 LONG을 포함하는 테이블에는 기본 키 또는 유니크 키가 정의되어 있어야 합니다. 테이블에 키가 없으면 SharePlex는 LONG 또는 LOB를 제외한 모든 컬럼에서 자체 키를 만듭니다. LOB 또는 LONG이 Post WHERE 절을 충족하는 두 행 간의 유일한 차이인 경우 Post는 잘못된 행을 업데이트할 수 있습니다.
• LOB가 포함된 테이블에 하나 이상의 명명된 Export 큐를 전용으로 지정합니다. 그러면 별도의 Export 프로세스가 자동으로 생성되고 자체 Post 프로세스가 포함된 명명된 Export 큐가 생성됩니다. LOB 데이터 유형의 처리를 다른 데이터의 처리와 분리함으로써 전체 복제 속도를 향상시킬 수 있습니다. 자세한 내용은 SharePlex 관리 안내서의 명명된 Export 큐 구성을 참조하십시오.
• LOB를 복제할 때 SharePlex에 충분한 공유 메모리가 있는지 확인하려면 SP_QUE_POST_SHMSIZE 매개변수를 초기 설정인 60MB로 늘립니다. SharePlex가 "Error: sp_cop process sp_mport/sp_opst_mt killed due to SIGSEGV"와 같은 공유 메모리 세그먼트 오류를 생성하는 경우 설정을 높입니다.
  

참고: 공유 메모리 세그먼트가 커지면 시스템에서 많은 양의 스왑 공간이 사용될 수 있으므로 사용 가능한 디스크 공간이 충분한지 확인하십시오.

SharePlex LOB 스토리지 관리

데이터베이스 설정 유틸리티는 선택한 테이블스페이스에 일부 테이블을 설치합니다. SHAREPLEX_LOBMAP 테이블을 제외한 모든 테이블은 테이블스페이스의 기본 스토리지 설정을 사용합니다.

SHAREPLEX_LOBMAP 테이블에는 행 외부에 저장된 LOB에 대한 항목이 포함되어 있습니다. 항목은 1MB INITIAL 익스텐트, 1MB NEXT 익스텐트, PCTINCREASE 10으로 생성됩니다. MAXEXTENTS는 120이므로 테이블을 120MB까지 늘릴 수 있습니다.

기본 조치: 기본 키와 유니크 키에 대한 추가 로깅을 활성화하는 경우 SP_OCT_ENABLE_LOBMAP 매개변수를 0으로 설정할 수 있으며 SHAREPLEX_LOBMAP 테이블에는 아무것도 저장되지 않습니다. 이 경우 크기 증가를 고려할 필요가 없습니다. Read 프로세스의 성능을 최대화하려면 기본 키와 유니크 키에 대한 추가 로깅을 활성화하는 것이 좋습니다.

대체 조치: 기본 스토리지는 일반적으로 SHAREPLEX_LOBMAP에 충분하며 4백만 개가 넘는 LOB 항목이 허용됩니다. 복제할 Oracle 테이블에 자주 삽입되거나 업데이트되는 LOB 컬럼이 많은 경우, 이에 따라 SharePlex 테이블스페이스의 크기를 늘리는 것이 좋습니다. 이 테이블은 다른 SharePlex 테이블과 테이블스페이스를 공유한다는 점을 고려하십시오.

데이터베이스가 CBO(Cost-Based Optimizer)를 사용하고 SharePlex가 처리하는 테이블에 다수의 LOB가 포함되어 있는 경우 SHAREPLEX_LOBMAP 테이블을 분석 일정에 포함합니다.

참고: SharePlex를 새로 설치해도 이전 설치의 스토리지 매개변수는 변경되지 않습니다.

시스템 프로세스 우선순위 설정

Oracle 또는 다른 프로세스에 리소스 우선순위가 할당된 경우 SharePlex는 기본 설정으로 유지되고 리소스 할당이 거의 없을 수 있습니다. Oracle은 처리량이 가장 많을 때 CPU 사용률을 높입니다. SharePlex가 Oracle에 비해 속도가 떨어지면 프로세스 우선순위를 높여볼 수 있습니다.

Unix에서 프로세스 우선순위를 설정하려면 다음을 수행합니다.

nice 명령을 사용합니다. 시스템에서 실행되는 모든 소프트웨어의 요구 사항에 따라 적절한 값을 선택하려면 시스템 관리자에게 문의하십시오. 루트 사용자는 프로세스의 niceness 값을 수정할 수 있습니다. SharePlex 관리자 사용자는 SharePlex의 niceness 값을 조정할 수 있습니다.

Oracle direct path loads 활성화

기본적으로 SharePlex는 SQL*Loader direct path loads(DIRECT=TRUE 키워드 매개변수)를 통해 테이블에 대한 변경 사항을 복제합니다. 여러 테이블에서 동시 로드가 있을 수 있지만 테이블당 하나의 로드만 있을 수 있습니다(PARALLEL=FALSE). 데이터베이스는 아카이브 모드여야 하며 테이블 로깅이 활성화되어 있어야 합니다.

소스 시스템에서 direct path loads가 장기간 지속될 것으로 예상되는 경우, 복제에 의존하지 않고 타겟 데이터베이스에 직접 데이터를 로드하는 것이 더 효율적일 수 있습니다. 대규모 direct path loads로 인해 Capture는 사용자 애플리케이션 활동에서 리두 로그를 입력하는 변경 사항을 따라잡지 못할 수 있습니다.

로드 후에는 체크 제약 조건을 비활성화해야 합니다. ON DELETE CASCADE 제약 조건을 활성화된 상태로 둘 수 있습니다.

SP_OCT_REPLICATE_DLOAD 매개변수는 direct path loads의 복제 여부를 제어합니다. direct path loads의 복제를 비활성화하려면 이 매개변수를 0으로 변경합니다. 자세한 내용은 SharePlex 참조 안내서를 참조하십시오.

압축 사용

압축을 활성화하여 SharePlex가 네트워크를 통해 전송하는 데이터의 양을 줄일 수 있습니다. SharePlex는 LZIP 무손실 압축을 사용합니다. 소스 SharePlex 인스턴스에서 압축을 활성화하면 소스 SharePlex 인스턴스의 모든 타겟에 대한 압축이 자동으로 활성화됩니다.

기본적으로 압축은 비활성화되어 있습니다. 압축을 단독으로 활성화하거나 암호화와 함께 활성화할 수 있습니다. 암호화에 대한 자세한 내용은 SharePlex 관리 안내서를 참조하십시오.

압축을 활성화하려면 다음을 수행합니다.

SP_XPT_ENABLE_COMPRESSION 매개변수를 1로 설정합니다.

sp_ctrl> set param SP_XPT_ENABLE_COMPRESSION 1

매개변수를 설정한 후 활성화하려면 Export를 중지했다가 시작합니다.

데이터 펌프 내보내기 지원 구성

Oracle 데이터 펌프 내보내기 작업을 복제하는 경우 SP_OCT_ALLOW_DP_DDL 매개변수를 1로 설정한 후 Capture를 재시작합니다.

SharePlex가 Oracle 데이터 펌프 익스포트/임포트를 실행할 때 발생하는 DDL 작업을 복제하지 못하는 경우 이 매개변수를 활성화할 수 있습니다. 경우에 따라 SharePlex는 무시해야 하는 순환 DDL로 Data Pump 로드의 DDL을 식별합니다. 이 매개변수는 해당 DDL을 캡처하도록 SharePlex에 지시합니다.

1로 설정하면 이 매개변수가 활성화됩니다. 로드가 완료되면 이 매개변수를 다시 0으로 설정한 후 Capture를 재시작합니다.