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

SharePlex 11.4 - 관리 안내서

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

Oracle DDL 복제 문제 해결

이 섹션에서는 Oracle DDL의 복제가 활성화될 때 발생하는 여러 가지 일반적인 문제와 해결 방법을 살펴봅니다. SharePlex DDL 지원에 대한 자세한 내용은 DDL 복제 구성를 참조하십시오.

현재 발생한 문제가 이 문서에 나오지 않은 경우 SharePlex 기술 문서를 https://support.quest.com에서 검색하십시오.

기술 문서에서는 SharePlex 사용 및 문제 해결에 도움이 될 수 있는 필터링 옵션과 기타 리소스에 대한 링크를 제공합니다.

DDL이 복제되지 않음

기본적으로 일부 Oracle DDL만 활성화됩니다. 다른 DDL 지원은 매개변수 설정을 통해 명시적으로 활성화되어야 합니다.

SP_OPO_STOP_ON_DDL_ERR 매개변수는 기본적으로 DDL을 적용하는 중에 오류가 발생하는 경우 Post 프로세스를 중지하도록 지시하여 문제를 수정하고 데이터베이스를 동기화된 상태로 유지할 수 있도록 합니다. 이 매개변수는 1(켜짐)로 설정되어야 합니다. 활성화되면 다음과 같은 메시지가 DDL을 건너뛰었음을 알려줍니다.

Skipping generic 9i DDL operation, schema (bob) could not be set.

FAILED DDL Replication for "create user bob."

해결 방법: 다음 매개변수가 적절하게 설정되어 있는지 확인하십시오. 이러한 매개변수를 사용하여 DDL 복제를 구성하는 방법에 대한 자세한 내용은 Oracle DDL 복제 제어를 참조하십시오.

  • SP_OCT_REPLICATE_DDL
  • SP_OCT_AUTOADD_ENABLE
  • SP_OCT_AUTOADD_MVIEW
  • SP_OCT_AUTOADD_SEQ
  • SP_OCT_REPLICATE_ALL_DDL

복제된 DDL이 이벤트 로그에 완전하게 표시되지 않음

SharePlex는 복제된 DDL을 이벤트 로그에 표시하지만 2,000자보다 긴 문은 자릅니다. 로그에는 처음 2,000자만 기록됩니다.

해결 방법: 필요하지 않습니다.

큐 문제 해결

이 항목은 SharePlex 큐와 관련될 수 있는 복제 문제를 해결하는 데 도움이 됩니다.

현재 발생한 문제가 이 문서에 나오지 않은 경우 SharePlex 기술 문서를 https://support.quest.com에서 검색하십시오.

기술 문서에서는 SharePlex 사용 및 문제 해결에 도움이 될 수 있는 필터링 옵션과 기타 리소스에 대한 링크를 제공합니다.

SharePlex에 디스크 공간이 부족함

큐에 데이터가 누적되면 SharePlex의 디스크 공간이 부족해질 수 있습니다. 다음은 몇 가지 가능한 원인과 해결 방법입니다.

문제 설명 해결 방법
복제 프로세스가 중지됨

복제 프로세스가 중지되면 데이터가 큐에 누적됩니다.

사용자에 의해 프로세스가 중단된 경우, SharePlex가 누적된 데이터를 처리할 수 있도록 원인을 파악한 후 빠른 시일 내에 프로세스를 시작하십시오. 오류로 인해 프로세스가 중지된 경우 show log 명령을 사용하여 이벤트 로그를 보고 발생한 문제를 확인한 다음, 문제를 해결하여 처리를 계속하고 큐 백로그를 줄일 수 있습니다.

대규모 작업

아직 COMMIT이 발생하지 않은 대규모 트랜잭션을 저장할 때 Post 큐가 커질 수 있습니다. 롤백 및 데이터 복구를 허용하기 위해 SharePlex는 COMMIT을 수신할 때까지 Post 큐에 데이터를 유지합니다.

qstatus 명령을 사용하여 Post 큐를 확인합니다. 백로그(메시지) 필드의 값이 일정하게 유지되거나 줄어들고, 메시지 수 필드의 값이 증가하는 경우 Post는 데이터를 릴리스하기 전에 COMMIT을 대기합니다.

Post가 트랜잭션을 정상적으로 처리하고 있는지 확인하려면 show post detail 명령을 사용합니다. 가능한 경우 애플리케이션의 COMMIT 지점을 500으로 설정하여 SharePlex가 처리할 더 작은 SQL 문을 생성합니다. 또한 긴 트랜잭션으로 알려진 테이블을 격리하는 명명된 Post 큐를 사용하는 구성을 생성하는 것을 고려해 보십시오. 자세한 내용은 명명된 Post 큐 구성를 참조하십시오.

Post 큐에 메시지가 누적되어 디스크 공간 문제가 발생할 위험이 있는 경우, Post가 다른 트랜잭션에서 일부 작업을 지울 때까지 Import를 중지할 수 있습니다. 자세한 내용은 디스크 공간 부족을 해결하는 방법를 참조하십시오.

(Oracle) Capture가 아카이브 로그를 처리 중임

Capture가 아카이브 로그를 처리하는 경우 아카이브된 레코드가 처리되는 동안 Capture 큐는 디스크 공간을 사용합니다.

로그의 Capture 위치가 데이터베이스 위치보다 훨씬 뒤에 있으면 소스와 타겟 데이터 간의 지연 시간이 너무 커서 타겟 사용자가 수용하지 못할 수 있습니다. variable-data 디렉토리에 더 많은 디스크 공간을 추가하는 대신 ora_cleansp를 실행하여 복제 환경과 큐를 정리하고 데이터를 재동기화하고 구성을 다시 활성화하는 것이 더 실용적일 수 있습니다.

Capture가 아카이브 로그를 처리하고 있어 SharePlex에 디스크 공간이 계속 부족해지는 경우 SharePlex 지원 팀이 Capture의 성능을 조정하고 리두 구성을 조정하는 데 도움을 줄 수 있습니다.

소스 트랜잭션 활동의 예기치 않은 증가

소스 시스템에서 예기치 않은 활동 증가로 인해 데이터가 Post 큐에 누적되어 할당된 디스크 공간의 최대 크기에 도달할 수 있습니다.

자세한 내용은 디스크 공간 부족을 해결하는 방법를 참조하십시오.

"큐 쓰기 및 열기 실패" 오류가 있음

이벤트 로그에 다음과 비슷한 일련의 메시지가 있으면 sp_cop을 중지한 후 시작하십시오.

1 08-06-12 13:20:17.089485 2384 1 sp_ordr(rim) (for o.user queue o.user) Error opening output queue rv=9 que_open(-,writeuser+ X,0x0a02d364+PR+o.user+sp_ordr+o.user)

Notice 08-06-12 13:20:17.089485 2384 1 sp_ordr (for o.user queue o.user) data route to a02d364.48.7e failed err=100

Error 08-06-12 13:20:17.089485 2384 1 sp_ordr (for o.user queue o.user) 11004 - sp_ordr failure writing to queue(s)

Notice 08-06-12 13:20:17.089485 2384 1 sp_ordr (for o.user queue o.user) Exit sp_ordr to retry rim-write.

Info 08-06-12 13:20:17.089485 2384 1 Process exited sp_ordr (for o.user queue o.user) [pid = 8183] - exit(1)

큐가 손상됨

SharePlex를 호스팅하는 시스템에 오류가 발생하면 하나 이상의 SharePlex 큐가 손상될 수 있으며 해당 큐에서 읽고 쓰는 데 오류가 발생합니다. 이 경우 purge config 및 abort config 명령은 작동하기 위해 큐를 활용하기 때문에 사용할 수 없습니다.

해결 방법: 큐 손상 문제를 해결하려면 SharePlex 지원 팀에 문의하십시오.

Post 큐가 너무 큰 것 같음

Post 큐의 크기가 포함된 메시지 수에 비해 너무 큰 경우 이는 드문 일이 아닙니다. SharePlex Post 큐는 실제로 여러 개의 하위 큐로 구성되며, 각각은 대략적으로 소스 시스템의 사용자 세션에 해당합니다. 하위 큐에는 하나 이상의 파일이 연결될 수 있으며 각 파일의 기본 크기는 8MB입니다. 8MB 크기를 모두 사용하지 않으면 데이터가 게시되고 읽기 해제된 후에도 파일이 시스템에 남아 있습니다.

해결 방법: 상태 표시의 Post 큐 크기는 모든 큐 파일에서 사용하는 실제 디스크 공간입니다. SharePlex qview 유틸리티에서 trim 명령을 사용하여 읽기 해제된 오래된 파일을 제거할 수 있습니다. 이 명령은 타겟 데이터베이스에 아직 게시 및 커밋되지 않은 데이터가 포함된 파일을 보존합니다. qview 유틸리티에 대한 자세한 내용은 SharePlex 참조 안내서를 참조하십시오.

동기화 문제 해결

이 섹션에서는 일반적인 동기화 문제의 원인과 해결 방법을 살펴봅니다. 이 해결 방법을 시도했지만 여전히 문제가 있는 경우 Quest 지원에 문의하십시오.

자세한 내용은 동기화의 개념 이해를 참조하십시오.

현재 발생한 문제가 이 문서에 나오지 않은 경우 SharePlex 기술 문서를 https://support.quest.com에서 검색하십시오.

기술 문서에서는 SharePlex 사용 및 문제 해결에 도움이 될 수 있는 필터링 옵션과 기타 리소스에 대한 링크를 제공합니다.

동기화 SharePlex중단 상태를 보고하는 방법

변환과 관련된 객체를 제외한 모든 객체에 대해 SharePlex는 복제된 데이터를 타겟에 게시하기 전에 지정된 작업의 소스 및 타겟 데이터가 동기화되었는지 확인합니다. 다음과 같은 이유로 변환이 사용되는 경우 SharePlex는 동기화를 확인하지 않습니다.

  • 변환하여 타겟 데이터 변경(전후 이미지를 비교할 수 없음)
  • 변환 루틴이 SharePlex가 아닌 데이터를 게시함

SharePlex가 소스 데이터와 타겟 데이터가 다르다고 판단하면 오류 상태를 생성하지만 Post 큐에서 다른 데이터를 계속 게시합니다. Post가 동기화 중단 상태를 감지한 경우 처리를 완전히 중지하도록 지시하려면 SP_OPO_OUT_OF_SYNC_SUSPEND(Oracle) 또는 SP_OPX_OUT_OF_SYNC_SUSPEND(Open Target) 매개변수를 변경합니다. SharePlex 참조 안내서의 Post 매개변수 문서를 참조하십시오.

동기화 중단 상태가 발생하면 Post 프로세스가 상태 데이터베이스와 이벤트 로그에 메시지를 기록합니다. sp_ctrl에서 이러한 파일을 보려면 다음을 수행합니다.

  • 상태 데이터베이스: show statusdb 또는 show sync 명령을 사용합니다.
  • 이벤트 로그: show log 명령을 사용합니다.

동기화 중단 오류를 모니터링하려면 이러한 명령을 자주 사용하십시오.

다음은 SharePlex가 동기화 중단 상태를 보고하는 방법에 대한 예입니다.

sp_ctrl (irvspxu14:8567)> show sync

Out Of Sync Status Database irvspxu14

Count Details

----- --------------------

3 Table "SCOTT"."TG_TEST1" out of sync for queue irvspxu14 since 16-Jun-

08 17:06:33

3 Table "SCOTT"."TG_TEST2" out of sync for queue irvspxu14 since 17-Jun-

08 15:47:58

1 Table "SCOTT"."TG_TEST3" out of sync for queue irvspxu14 since 17-Jun-

08 15:52:03

데이터가 동기화되지 않으면 SharePlex는 실패한 SQL 문을 SharePlex variable-data 디렉토리의 data 하위 디렉토리에 있는 database_ID_errlog.sql 파일에 기록합니다.

중요: 상태 데이터베이스와 이벤트 로그에 동기화 중단 메시지가 표시되지만 해당 트랜잭션에 대한 database_ID_errlog.sql 파일에 레코드가 없는 경우, 해당 메시지를 무시하지 마십시오. 해당 메시지는 ROLLBACK과 연관될 수 있습니다. 트랜잭션의 롤백 여부에 관계없이 SharePlex는 계속해서 소스 행과 타겟 행의 사전 이미지를 비교합니다. 이미지가 서로 다른 경우에는 데이터가 동기화되지 않은 것입니다. SharePlex는 소스에서는 트랜잭션이 커밋되었지만 타겟에서는 실패한 경우에만 해당 트랜잭션을 database_ID_errlog.sql file에 기록하여 문제 해결 및 수동으로 문을 적용하기 위한(가능한 경우) 도구로 적용해야 하는 문의 레코드를 제공합니다. 롤백된 문은 취소된 작업이므로 타겟에 기록되지 않습니다.

동기화 중단 상태 거짓 감지

경우에 따라 동기화 중단 메시지는 거짓일 수 있으며 해당 데이터가 동기화 중단 상태가 아닐 수 있습니다. compare 명령을 사용하여 소스 데이터와 타겟 데이터를 비교할 수도 있고, 다음 비교를 수동으로 수행할 수도 있습니다.

compare 명령으로 비교하려면 다음을 수행합니다.

SharePlex 참조 안내서의 compare 명령을 참조하십시오.

데이터가 동기화 중단 상태인지 확인하려면 다음을 수행합니다.

  1. 타겟 시스템의 variable-data 디렉토리에 있는 database_ID_errlog.sql 파일에서 영향을 받은 행의 rowid를 가져옵니다.
  2. WHERE 절의 rowid를 사용해 소스 테이블에서 SELECT 쿼리를 실행하여 이 rowid에 대한 행 데이터를 가져옵니다.
  3. WHERE 절의 소스 쿼리에서 가져온 행 데이터를 사용하여 타겟 테이블에서 SELECT 쿼리를 실행합니다.
  4. 쿼리 결과를 비교합니다. 결과가 서로 다른 경우 행이 동기화되지 않은 것입니다. 결과가 같으면 행이 동기화된 것입니다.

참고: 테이블에 고유한 컬럼이 없으면 Compare에 잘못된 결과가 표시될 수 있습니다.

일반적인 동기화 중단 상태 및 해결 방법

다음은 데이터가 동기화되지 않는 일반적인 방식입니다. 대부분의 경우 SharePlex는 동기화 중단 상태를 감지하고 오류 메시지를 반환하지만, 동기화 중단 상태가 숨겨져 있어 SharePlex가 오류를 반환하지 않는 경우도 있습니다.

동기화 중단 상태 설명 해결 방법

잘못된 정리 프로시저

database_cleansp 정리 유틸리티 중 하나가 활성 구성과 연결된 전체가 아닌 일부 시스템에서 실행된 경우 SharePlex는 동기화 중단 상태를 감지합니다.

이벤트 로그를 확인하여 모든 시스템에서 정리 유틸리티가 실행되었는지 여부를 확인합니다. 로그에 각 시스템에서 실행되었는지 여부와 시기가 표시됩니다. 또한 구성이 활성화되었는지 여부와 시기도 표시됩니다. 해당 이벤트의 시간을 비교하여 발생한 상황을 확인할 수 있습니다.

이 구성에 대한 모든 복제 시스템에서 정리가 완료되지 않은 경우 모든 시스템에서 정리 유틸리티를 실행합니다. 정리를 수행하면 복제 큐 및 프로세스가 제거되고 구성이 비활성화되므로 초기 동기화를 다시 수행해야 합니다.

DDL 변경 사항

동기화 중단 상태의 일부 DDL 관련 원인은 다음과 같습니다.

  • 복제되지 않은 DDL 변경 사항이 소스 객체에 적용되지만 객체를 다시 분석할 수 있도록 구성이 다시 활성화되지 않았습니다.
  • SharePlex가 복제하는 DDL도 타겟에서 수동으로 수행됩니다.

지원되는 DDL 목록은 SharePlex 릴리스 노트를 참조하십시오.

수동으로 및 SharePlex에 의해 수행된 중복 DDL 변경 사항을 실행 취소하려면 다음을 수행합니다.

  1. Post 프로세스를 중지합니다(이미 중지되었을 수 있음).

    sp_ctrl(sysB)> stop post

  2. DDL 변경 사항을 실행 취소하려면 타겟 테이블을 변경합니다.

  3. Post를 시작하고 SharePlex가 복제된 DDL(아직 Post 큐에 있음)을 게시하도록 합니다.

    sp_ctrl(sysB)> start post

 

DML 변경 사항이 타겟에 직접 적용됨 애플리케이션이나 사용자가 타겟의 테이블에 DML을 변경하면 Post가 영향을 받는 행에 복제된 변경 사항을 적용할 때까지 이러한 변경 결과로 인해 숨겨진 동기화 중단 상태가 발생합니다. 변경 사항이 적용되면 SharePlex가 동기화 중단 오류를 반환합니다.

복제 중인 타겟 테이블에 대한 모든 DML 접근을 금지합니다.

compare 및 repair 명령을 사용하여 테이블에서 동기화 중단 행을 비교한 다음, 해당 행을 복원할 수 있습니다. 자세한 내용은 SharePlex 참조 안내서의 명령 문서를 참조하십시오.

타겟 객체에서 트리거

트리거를 타겟 객체에서 비활성화해야 합니다. 트리거는 소스 시스템에서 실행되고 SharePlex는 해당 효과를 타겟에 복제합니다.

타겟 시스템에서 트리거가 실행된 경우 트리거에 의해 변경된 객체는 동기화되지 않았으므로 재동기화해야 합니다. 자세한 내용은 소스 및 타겟 테이블을 재동기화하는 방법를 참조하십시오.

데이터가 재동기화된 후 타겟 Oracle 객체에 대한 트리거 효과를 비활성화하려면 다음 중 하나를 수행합니다.

  1. SharePlex Oracle 사용자를 무시하도록 트리거에 지시하는 sp_add_trigger.sql 스크립트를 실행합니다. 트리거 스크립트에 대한 자세한 내용은 SharePlex 참조 안내서의 유틸리티 문서를 참조하십시오.

  2. 필요하지 않은 경우 트리거를 비활성화합니다.
불필요한 제약 조건

단방향 복제 구성에서 타겟 테이블에 필요한 유일한 제약 조건은 기본 키 제약 조건과 유니크 키 제약 조건입니다. 체크 제약 조건은 소스에서 충족되기 때문에 타겟에서는 필요하지 않습니다. FOREIGN KEY 및 ON DELETE CASCADE 제약 조건도 소스에서 충족되며 SharePlex는 하위 작업을 타겟의 올바른 테이블에 복제합니다.

Oracle 타겟의 경우 ON DELETE CASCADE 제약 조건을 무시하도록 SharePlex를 구성하면 활성화 상태로 유지할 수 있습니다.

복제된 객체에 대한 제약 사항을 다루는 방법은 복제를 위한 Oracle 데이터베이스 객체 설정복제를 위한 Oracle 데이터베이스 객체 설정

구성 파일의 항목이 중복됨 소스, 타겟 및 라우팅 맵이 동일한 중복 항목이 있어 타겟에 이중 게시가 발생합니다.

구성 파일을 새 파일에 복사합니다.

새 파일에서 중복된 항목을 찾아서 제거합니다.

재동기화 및 다시 활성화를 수행합니다. 자세한 내용은 소스 및 타겟 테이블을 재동기화하는 방법를 참조하십시오.

디스크 공간 부족

SharePlex에 큐에 수용할 충분한 공간이 없을 때 사용자 트랜잭션이 계속되면 데이터가 동기화되지 않습니다. 다음과 같은 경우에 이 문제가 발생할 수 있습니다.

  • 네트워크 또는 타겟 시스템을 사용할 수 없으며 Export 큐에 너무 많은 데이터가 축적되었습니다.
  • 타겟을 사용할 수 없으며 Post 큐에 너무 많은 데이터가 축적되었습니다.
  • Capture의 소스 트랜잭션 로깅 속도가 느려졌습니다. 이 경우 Capture 큐에 데이터가 누적됩니다.
  • SharePlex 프로세스가 중지되었지만 재시작되지 않았습니다.
  • flush 명령이 실행되었지만 Post가 다시 시작되지 않았습니다.
자세한 내용은 디스크 공간 부족을 해결하는 방법를 참조하십시오.

수평으로 파티셔닝된 복제의 컬럼 조건 변경

다음과 같은 경우 수평으로 파티셔닝된 복제를 사용하면 동기화 중단 상태가 발생할 수 있습니다.

  • 컬럼 조건 값이 업데이트되고 새 값이 더 이상 행 선택 기준을 충족하지 않습니다.
  • 컬럼 조건을 충족하지 않는 행이 조건을 충족하도록 업데이트됩니다.

파티션 이동이 발생하지 않도록 컬럼 조건을 만듭니다. 자세한 내용은 수평으로 파티셔닝된 복제 구성를 참조하십시오.

구성 변경 후 다시 활성화되지 않음

테이블이 구성에 추가되었지만 구성이 다시 활성화되지 않은 경우, 해당 테이블에 대한 작업은 복제되지 않습니다.

참고: Oracle 소스 테이블의 경우 자동 추가 기능이 기본적으로 활성화되어 있으며, 해당 이름이 구성 파일의 와일드카드를 충족하는 모든 새 테이블이 복제에 자동으로 추가됩니다. 자세한 내용은 Oracle DDL 복제 제어를 참조하십시오.

영향을 받은 테이블을 재동기화한 다음, SharePlex가 해당 객체 캐시를 업데이트할 수 있도록 구성을 다시 활성화합니다. 자세한 내용은 소스 및 타겟 테이블을 재동기화하는 방법를 참조하십시오.

큐 손상

시스템 장애 등으로 인해 SharePlex 큐가 손상된 경우 해당 큐의 데이터가 손실될 수 있습니다. 이 문제를 해결하려면 재동기화가 필요합니다.

자세한 내용은 소스 및 타겟 테이블을 재동기화하는 방법를 참조하십시오.

(Oracle) 시스템 장애 시 큐 손상을 방지하려면 SP_QUE_SYNC 매개변수를 사용하면 됩니다. SharePlex 참조 안내서의 큐 매개변수 문서를 참조하십시오.

Oracle 관련 동기화 중단 상태 및 해결 방법

다음은 특히 Oracle 데이터베이스 간의 복제와 관련된 일반적인 동기화 문제입니다. 대부분의 경우 SharePlex는 동기화 중단 상태를 감지하고 오류 메시지를 반환하지만, 동기화 중단 상태가 숨겨져 있어 SharePlex가 오류를 반환하지 않는 경우도 있습니다.

동기화 중단 상태 설명 해결 방법
DDL 변경 사항

동기화 중단 상태의 일부 DDL 관련 원인은 다음과 같습니다.

  • 복제되지 않은 DDL 변경 사항이 소스 객체에 적용되지만 객체를 다시 분석할 수 있도록 구성이 다시 활성화되지 않았습니다.
  • SharePlex가 복제하는 DDL도 타겟에서 수동으로 수행됩니다.

지원되는 DDL 목록은 SharePlex 릴리스 노트를 참조하십시오.

수동으로 및 SharePlex에 의해 수행된 중복 DDL 변경 사항을 실행 취소하려면 다음을 수행합니다.

  1. Post 프로세스를 중지합니다(이미 중지되었을 수 있음).

    sp_ctrl(sysB)> stop post

  2. DDL 변경 사항을 실행 취소하려면 타겟 테이블을 변경합니다.

  3. Post를 시작하고 SharePlex가 복제된 DDL(아직 Post 큐에 있음)을 게시하도록 합니다.

    sp_ctrl(sysB)> start post

 

부적절하거나 존재하지 않는 충돌 해결 루틴

피어-투-피어(활성-활성) 구성에서는 충돌 해결 프로시저가 필요합니다. SharePlex는 충돌 해결 프로시저를 사용하여 동일한 데이터 변경 사항이 다른 시스템에서 수신될 때 게시할 작업을 결정합니다.

충돌 해결 프로시저를 수정하고 테스트한 후 데이터를 재동기화합니다. 자세한 내용은 소스 및 타겟 테이블을 재동기화하는 방법를 참조하십시오.
로그 래핑

필요한 데이터를 Capture가 처리하기 전에 리두 로그가 래핑되는 경우, 아카이브된 로깅이 활성화되지 않거나 Capture에 필요한 아카이브가 로그가 제거되면 데이터가 동기화되지 않을 수 있습니다. (일반적으로 Capture는 아카이브 로그에 접근하여 복제를 계속합니다.)
  • 먼저 문제 해결
  • 아카이빙이 활성화되지 않으면 SharePlex에 대해 읽을 아카이브가 로그가 없습니다. 로그 래핑 이후에 손실된 데이터는 복구할 수 없습니다. 아카이브된 로깅을 활성화하고 데이터를 재동기화합니다. 자세한 내용은 소스 및 타겟 테이블을 재동기화하는 방법를 참조하십시오.
  • SharePlex에 Oracle 뒤에 있는 로그가 많은 경우 로그를 복원하는 대신 데이터를 재동기화하는 것이 좋습니다. 재동기화는 아카이브 로그에서 누락된 레코드를 처리하는 데 Capture에 걸리는 시간보다 시간이 덜 걸릴 수 있습니다. 또한 아카이브 로그를 처리하는 동안 Capture 큐가 여유 디스크 공간을 초과할 가능성이 줄어듭니다. 리두 로그의 크기와 복제되는 테이블 수(둘 다 Capture에서 처리해야 하는 정보의 양을 결정함)에 따라 결정을 내릴 수 있습니다. 또한 타겟 데이터 사용자가 허용할 수 있는 지연 시간도 고려합니다.
  • 아카이브 로그를 사용할 수 있는 경우 해당 로그를 소스 시스템의 아카이브-로그 디렉토리에 다시 복사하거나 SP_OCT_ARCH_LOC 매개변수를 사용하여 SharePlex가 해당 위치를 가리키도록 합니다.
LONG 컬럼

테이블에 기본 키 또는 유니크 키가 없는 경우 SharePlex는 LONG 컬럼과 LOB 컬럼을 제외한 모든 컬럼을 기반으로 시뮬레이션된 키를 빌드합니다. 타겟 행의 LONG 컬럼이 고유 값을 포함하는 유일한 컬럼인 경우, 여러 행이 시뮬레이션된 키에 대한 기준을 충족할 수 있습니다. SharePlex는 오류가 감지되지 않은 상태로 잘못된 행에 UPDATE 또는 DELETE를 적용하여 오류 메시지 없이 테이블의 동기화가 중단될 수 있습니다.

타겟 테이블의 고유성을 보장하는 컬럼에서 키를 생성할 수 있으면 이러한 종류의 동기화 중단 상태를 방지할 수 있습니다. 키를 생성한 후 SharePlex가 해당 객체 캐시를 업데이트할 수 있도록 해당 객체를 재동기화하고 다시 활성화합니다.

기본 키 또는 유니크 키를 추가할 수 없는 경우(예: 패키징된 애플리케이션을 사용 중인 경우) 타겟 시스템에서 행의 고유성을 보장할 수 없습니다.

키 변경

테이블이 자동으로 생성된 숫자 시퀀스를 키로 사용하고 키 값이 변경되면 타겟 시스템에 중복이 발생할 수 있습니다. 새 값이 타겟 시스템의 다른 행에 키로 이미 존재하는 경우 SharePlex가 고유-키 제약 조건 위반 및 동기화 중단 오류를 반환합니다. 이 문제는 x +n 공식을 사용하여 값을 업데이트할 때 발생할 수 있습니다. 여기서 n은 증분 증가입니다. x +n 값 중 하나가 기존 값과 같을 가능성이 있습니다.

업데이트로 인해 타겟 시스템에서 키가 중복되지 않도록 시퀀스를 생성합니다.
소스 및/또는 타겟 시스템에서 실행 중인 DBMS_SCHEDULER 프로시저 복제 외부에서 객체 생성, 조작 및 삭제 등 이러한 프로시저의 효과는 복제에 표시되지 않거나 지원되지 않을 수 있으며, 이로 인해 데이터 변경이 동기화 중단 상태를 초래할 수 있습니다. 작업에서 소스 및 타겟 객체를 제외합니다.
가상 프라이빗 데이터베이스 가상 프라이빗 데이터베이스로 구성된 데이터를 복제하는 경우 SharePlex 데이터베이스 사용자는 데이터를 캡처할 수 있는 접근 권한이 없을 수 있습니다. 해당 데이터에 대한 변경 사항은 타겟에 반영되지 않습니다.

해당 데이터를 타겟에 복제할 필요가 없으면 파티셔닝된 복제를 통해 SharePlex 구성에서 해당 데이터를 필터링할 수 있습니다.

데이터를 복제하려면 SharePlex 사용자에게 올바른 접근 권한을 할당합니다.

PK/UK 로깅이 활성화되지 않음 특정 복제 문제는 키 값을 기록하여 예방할 수 있습니다. SharePlex는 rowid를 기반으로 키 값을 가져옵니다. ALTER TABLE...MOVE와 같이 rowid를 변경하는 작업으로 인해 후속 DML 작업에 잘못된 키 값이 사용될 수 있습니다. SharePlex에서는 기본 키와 유니크 키 보충 로깅을 모두 설정하거나, 복제의 모든 테이블에 대해 고유 컬럼의 보충 로그 그룹을 정의하는 것을 권장합니다.

먼저 문제 해결

데이터가 동기화 중단 상태인 경우 데이터를 재동기화하기 전에 다음을 수행합니다.

  1. 데이터를 재동기화하기 전에 문제가 발생한 이유를 확인하십시오. 확인하지 않으면 문제가 반복되어 더 많은 데이터가 동기화되지 않을 수 있습니다.
  2. 추가 오류를 방지하려면 Post 프로세스를 중지합니다. Post 큐에 메시지가 누적되어 디스크 공간 문제가 발생할 위험이 있고 소스 시스템에 사용 가능한 디스크 공간이 충분한 경우, Post가 다른 트랜잭션에서 일부 작업을 지울 수 있을 때까지 Import를 중지할 수 있습니다. 자세한 내용은 디스크 공간 부족을 해결하는 방법를 참조하십시오.
  3. 상태 데이터베이스와 이벤트 로그를 확인하여 문제의 원인을 살펴봅니다.
  4. 문제를 해결합니다.

데이터 재동기화

자세한 내용은 소스 및 타겟 테이블을 재동기화하는 방법를 참조하십시오.

compare 명령 오류 해결

compare 또는 repair 명령에 문제가 있는 경우 다음을 참조하여 지원을 받으십시오.

현재 발생한 문제가 이 문서에 나오지 않은 경우 SharePlex 기술 문서를 https://support.quest.com에서 검색하십시오.

기술 문서에서는 SharePlex 사용 및 문제 해결에 도움이 될 수 있는 필터링 옵션과 기타 리소스에 대한 링크를 제공합니다.

문제 설명 해결 방법
Oracle 오류 904

Error 904 calling oexec in de_select_prepare_to_fetch.

비교되는 소스 테이블과 타겟 테이블이 구조적으로 다르기 때문에 비교에 실패했습니다. compare 및 repair 명령은 동기화되지 않은 DDL 작업이나 구조적으로 동일하지 않은 테이블로 인해 발생한 동기화 중단 상태를 감지하고 복원하지 않습니다.

두 테이블 모두에 대해 DESCRIBE를 실행합니다. 아마도 테이블에 동일한 수의 컬럼이 없거나 데이터 유형이 다르다는 것이 표시될 것입니다. DDL 문제를 해결한 후 repair를 실행하여 행의 값을 재동기화할 수 있습니다.

"사용자가 너무 많음” 오류

Can not add DataEquator queue reader que_TOOMANYUSERS: User table is full.

SharePlex 큐에서 읽고 쓰는 최대 프로세스 수가 초과되었습니다. 복제 프로세스와 compare와 repair 프로세스를 포함하여 20개가 넘는 프로세스를 Post 큐에서 동시에 읽고 쓸 수 없습니다. 복원 옵션을 사용하면 오류가 발생할 가능성이 매우 높습니다. 복원은 복원하지 않은 비교보다 큐에 훨씬 더 오래 접근하기 때문입니다.

제한을 조정하는 해결 방법이나 방법은 없으며, 제한을 초과하지 않고 동시에 실행할 수 있는 Compare 프로세스 수를 결정할 방법도 없습니다.

팁: 프로세스 제한에 얽매이지 않고 동시에 여러 테이블을 비교하려면 compare using 명령을 사용하십시오. 비교되는 테이블을 제한하려면 비교할 테이블만 포함하는 새 구성을 생성하고 이를 비교에 사용하십시오. (해당 구성을 활성화하지 마십시오.) 모든 테이블은 프로세스를 사용하여 한 번의 비교를 통해 비교됩니다.

클라이언트 프로세스 종료에 실패함

sp_desvr 서버 프로세스가 종료되면 일반적으로 관련 sp_declt 클라이언트 프로세스도 종료됩니다. 프로세스가 종료되지 않으면 사용자가 종료할 수 있습니다.

 자세한 내용은 Compare 프로세스 종료를 참조하십시오.
서버 프로세스 종료에 실패함 sp_declt 클라이언트 프로세스를 종료하거나 자체적으로 종료되거나, sp_desvr 서버 프로세스가 클라이언트와 통신하지 않은 경우 sp_desvr 서버 프로세스는 일반적으로 일정 시간이 지난 후 종료됩니다. 이는 SP_DEQ_TIMEOUT 매개변수에 의해 제어됩니다. 자세한 내용은 Compare 프로세스 종료를 참조하십시오.

Compare 프로세스 종료

클라이언트 프로세스를 종료하려면 다음을 수행합니다.

sp_declt 클라이언트 프로세스를 종료해야 하고 여러 비교가 실행 중인 경우, 다음 방법 중 하나로 종료할 프로세스를 결정할 수 있습니다.

  • sp_declt 로그 파일 보기 — 파일에서 sp_declt 프로세스의 세션 ID를 살펴보고 종료된 sp_desvr 프로세스의 PID와 일치하는 세션 ID를 찾습니다. 그것이 종료할 sp_declt 프로세스입니다. sp_declt 세션 ID는 연관된 sp_desvr 프로세스의 PID와 동일합니다.

  • 이벤트 로그 보기 — 이벤트 로그는 각 sp_declt 클라이언트 프로세스의 시작과 해당 PID를 기록합니다. 로그의 후속 항목은 프로세스가 작성 중인 비교 로그 파일을 기록합니다. 해당 항목의 비교 로그 파일 이름에는 서버 프로세스의 PID가 있습니다. 예를 들어 다음 샘플 항목에서 sp_declt 프로세스 PID는 2450입니다. 프로세스는 비교 로그 ../o734v32a_declt-1228-01.log에 작성합니다. 1228은 서버 프로세스의 PID입니다.

    05/04/01 17:01 Process launched: sp_declt (for o.o734v32a-o.o734v32a- 87056 queue all) [pid = 2450]

    05/04/01 17:01 Notice: sp_declt(deq) (for o.o734v32a-o.o734v32a-87056 queue all) Opened DataEquator session log file /u10/julia30014/var7/ log/o734v32a_declt-1228-01.log

    종료된 서버 프로세스에 대한 로그 파일 이름을 검색하고 해당 로그 파일과 연관된 클라이언트 프로세스를 찾아 종료할 올바른 PID를 결정할 수 있습니다.

서버 프로세스를 종료하려면 다음을 수행합니다.

sp_declt 클라이언트 프로세스가 종료될 때 sp_desvr 서버 프로세스를 종료해야 하는 경우, 이벤트 로그를 살펴보고 sp_declt 클라이언트 프로세스가 어떤 로그에 작성했는지 알아봅니다. 이벤트 로그는 각 클라이언트 프로세스의 시작과 해당 PID를 기록합니다. 로그의 후속 항목은 프로세스가 작성 중인 비교 로그 파일을 기록합니다. 해당 항목의 비교 로그 파일 이름에는 서버 프로세스의 PID가 있습니다. 예를 들어 다음 샘플 항목에서 sp_declt 프로세스 PID는 2450입니다. 프로세스는 로그 ../o734v32a_declt-1228-01.log에 작성합니다. 1228은 서버 프로세스의 PID이며, 이것이 종료할 프로세스입니다.

05/04/01 17:01 Process launched: sp_declt (for o.o734v32a-o.o734v32a- 87056 queue all) [pid = 2450]

05/04/01 17:01 Notice: sp_declt(deq) (for o.o734v32a-o.o734v32a-87056 queue all) Opened DataEquator session log file /u10/julia30014/var7/ log/o734v32a_declt-1228-01.log

The document was helpful.

평가 결과 선택

I easily found the information I needed.

평가 결과 선택