INDEX 힌트 사용
Oracle INDEX 힌트 사용
유효 항목: Oracle 타겟
SharePlex가 타겟 테이블에서 UPDATE 및 DELETE를 수행할 때 Oracle은 때때로 SharePlex에 대해 가장 효율적인 인덱스를 선택하지 않습니다. 올바른 인덱스가 없으면 여러 UPDATE 및 DELETE가 수행될 때 Post 프로세스 속도가 저하됩니다. SharePlex를 사용하면 Oracle의 INDEX 힌트를 활용하여 타겟 객체에 대한 올바른 인덱스 사용을 실행할 수 있습니다.
INDEX 힌트를 사용하려면 힌트를 사용합니다.SID 파일을 사용합니다. 여기서, SID는 타겟 인스턴스의 ORACLE_SID입니다. Post가 SQL 문을 적용하면 힌트 파일을 읽습니다. 파일에 항목이 포함된 경우 Post는 데이터를 메모리로 읽은 다음, 처리하는 각 UPDATE 및 DELETE 문을 확인합니다. 해당 작업에 힌트 파일에 나열된 테이블이 포함된 경우 Post는 Oracle에 힌트를 보냅니다.
힌트가 필요한 테이블에만 힌트를 사용하십시오. 예를 들어 정의된 인덱스가 있는 테이블에서 Post가 전체 테이블 검사를 수행하는 경우 해당 테이블에 대해서만 힌트를 사용합니다. 힌트를 사용하면 Post가 힌트를 읽게 됩니다.파일에 나열된 테이블의 각 작업에 대한 SID 파일입니다. 많은 테이블이 나열되면 처리 속도가 저하될 수 있습니다.
기본 최대 힌트 수(테이블/인덱스 쌍)는 100개입니다. SP_OPO_HINTS_LIMIT 매개변수를 사용하여 이 값을 조정할 수 있습니다. 자세한 내용은 SharePlex 참조 안내서를 참조하십시오.
모든 인덱스가 유효해야 합니다. SharePlex는 유효하지 않은 인덱스를 힌트로 사용하지만 Oracle은 유효하지 않은 힌트를 무시하고 오류를 반환하지 않습니다. 지정된 힌트와 관련된 비정상적인 조건을 SharePlex가 감지하면 event_Log에 다음 정보를 기록합니다.
15050 – hint file not found
17000 – error opening hint file
15051 – missing column in the hint file (either table or index name)
15052 – syntax error for tablename
15053 – syntax error for indexname
15054 – source table’s object_id not found in object cache
15055 – more than 20 valid entries were entered into the hints file
힌트 파일을 사용하려면 다음을 수행합니다.
빈 힌트가 있습니다.SID 파일은 각 시스템의 SharePlex variable-data 디렉토리에 있습니다. 힌트를 사용합니다.타겟 시스템에 있는 SID 파일입니다. 힌트 파일이 없으면 이 디렉토리에 힌트 파일을 만들고 힌트를 사용해야 합니다.SID 명명 형식입니다.
- Post가 실행 중인 경우 중지합니다.
- 파일을 엽니다.
- 파일의 어느 곳에나 주석 줄을 추가할 수 있습니다. 파운드 기호(#)로 주석 줄을 시작합니다.
-
주석 처리되지 않은 줄에서 다음 템플릿을 사용하여 소스 테이블과 해당 테이블에 사용할 인덱스를 지정합니다. 테이블 이름과 인덱스 이름 사이에 공백을 1개 이상 입력합니다. 각 사양을 별도의 줄에 배치합니다.
|
"src_owner"."table" |
"tgt_owner"."index" |
예
|
"scott"."emp" |
"scott"."emp_index" |
SQL 캐싱 조정
SharePlex는 자주 사용되는 SQL 문을 재사용하기 위해 캐시하므로 해당 문이 반복될 때마다 구문 분석하고 바인딩할 필요가 없습니다. 이는 SharePlex의 조정 가능한 기능으로, SQL 캐시라고 합니다. 애플리케이션이 생성하는 반복 문의 양에 따라 이점을 최대화하도록 이 기능을 조정할 수 있습니다.
SQL 캐시는 데이터 값 외에는 아무런 변화 없이 동일한 SQL 문이 반복해서 실행되는 경우에만 Post의 성능을 향상시킵니다. 사용자 환경이 그렇지 않은 경우 SQL 캐시는 Post 프로세스에 불필요한 오버헤드를 추가하므로 이를 비활성화해야 합니다.
지원되는 타겟
전체
SQL 캐시 활성화 또는 비활성화
다음과 같이 SQL 캐시를 제어합니다.
Oracle
|
SP_OPO_SQL_CACHE_DISABLE |
SQL 캐시를 활성화하거나 비활성화합니다. 기본적으로 0으로 설정되어 활성화됩니다. SQL 캐시를 비활성화하려면 매개변수를 1로 설정합니다. 일괄 작업에 대해서만 SQL 캐시를 비활성화하려면 매개변수를 3으로 설정합니다. 그러면 Post에서 사용하는 메모리 양이 줄어듭니다. |
|
SP_OPO_MAX_CDA |
Post 세션당 캐시할 활성 문의 수를 결정합니다. Post는 기본적으로 세션당 50개의 커서를 엽니다. 필요한 경우 이 설정을 늘리거나 줄일 수 있습니다. 자세한 내용은 열린 커서 조정를 참조하십시오. |
Open Target
|
SP_OPX_SQL_CACHE_DISABLE |
SQL 캐시를 활성화하거나 비활성화합니다. 기본적으로 0으로 설정되어 활성화됩니다. SQL 캐시를 비활성화하려면 매개변수를 1로 설정합니다. |
|
다음과 같이 target 명령을 사용합니다.
target r.database [queue queuename] set resources max_active_statements=number_of_active_statements |
Post 세션당 캐시할 활성 문의 수를 결정합니다. Open Target 데이터베이스의 경우 Post는 ODBC 드라이버에서 허용되는 활성 문 수를 가져옵니다. 해당 값이 max_active_statements 설정보다 낮으면 Post가 중지되고 오류가 반환됩니다. SQL 캐시 기능을 비활성화하거나 max_active_statements 값을 줄일 수 있습니다. |
최고의 성능을 위해 SQL 캐시 조정
활성 문 수가 복제되는 작업에 최적인지 확인하려면 다음 단계를 따릅니다.
- sp_ctrl을 실행하고 show post detail 명령을 실행하여 캐시된 문의 적중률을 결정합니다.
- SQL 캐시 적중 횟수 필드를 찾습니다. 이 필드는 구문 분석 및 바인딩 없이 실행된 총 메시지 수를 총 INSERT, UPDATE 및 DELETE 작업 수로 나눈 비율을 보여줍니다. 예를 들어 적중률이 36%라는 것은 Post가 캐시된 문을 36%의 시간 동안 사용하고 있음을 나타냅니다.
- 며칠 간의 일반적인 복제 활동 후 적중률을 확인하여 활성 문 수에 대한 이상적인 설정을 측정합니다. 적중률이 50% 미만인 경우 매개변수 값을 약 5개의 문 단위로 조금씩 늘립니다.
- 다음 며칠 동안 적중률을 모니터링합니다. 적중률이 증가하면 애플리케이션이 활성 문에 허용된 모든 커서를 사용하고 있음을 의미합니다. 적중률이 일정하게 유지될 때까지 계속해서 매개변수 값을 조금씩 증가시킵니다.
열린 커서 조정
유효 항목: Oracle 타겟
Oracle 매개변수 OPEN_CURSORS의 값은 Post 프로세스에서 예상되는 성능 수준을 지원할 수 있을 만큼 높게 설정되어야 합니다. 이 매개변수는 프로세스(예: Post)가 열 수 있는 최대 커서 수를 정의합니다.
내부적으로 Post는 OPEN_CURSORS 값에서 루틴 호출에 필요한 10을 뺀 열려 있는 최대 총 커서 수를 설정합니다. event_log에서 이 값을 확인합니다. 다음 예에서는 OPEN_CURSORS가 512로 설정됩니다.
Notice: sp_opst_mt (for o.oracle-o.oracle queue oracle) Post will not open more than 502 cursors (OPEN_CURSORS – 10).
Post는 열려 있는 커서 수에 대한 레코드를 유지합니다. Post는 최대 커서 수를 초과하는 것을 감지하면 가장 최근에 사용된 세션에서 가장 최근에 사용된 커서를 닫습니다.
커서 부족을 방지하기 위해 Post 프로세스는 시작 시 OPEN_CURSORS 값을 쿼리합니다. 값이 충분히 높지 않으면 Post는 event_log에 다음 경고를 작성합니다.
Warning: (sp_opst_mt for o.oracle-o.oracle queue oracle)Oracle parameter 'OPEN_CURSORS' is < number. Check 'OPEN_CURSORS' setting.
OPEN_CURSORS 값이 없으면 수정하거나 추가할 수 있습니다.
OPEN_CURSORS 값을 보려면 다음 SQL 문을 사용하여 데이터베이스를 쿼리합니다.
select value from v$parameter where name = 'open_cursors';
Post 프로세스에 충분히 높은 OPEN_CURSORS 값을 추정하려면 다음을 수행합니다.
- 타겟 인스턴스에 대해 예상되는 최대 동시 트랜잭션(세션) 수를 추정합니다. Post는 소스 시스템의 각 세션에 대해 타겟 시스템의 세션을 엽니다. 프로덕션이 최대 수준에 있을 때 sp_ctrl에서 show post detail 명령을 실행하여 트랜잭션 수를 정확하게 추정할 수 있습니다. 표시의 열린 트랜잭션 수 필드에는 동시 트랜잭션 수가 표시됩니다.
-
다음 공식을 사용하여 SharePlex(및 타겟 데이터에 접근할 수 있는 기타 애플리케이션)를 지원하기 위한 OPEN_CURSORS의 올바른 설정을 확인합니다.
SQL 캐시 활성화(기본값): 기본적으로 Post는 완료 후 닫히는 루틴 호출을 위해 10개의 커서와 트랜잭션당 최소 7개의 커서(기본 최소값 2개 + 추가 5개)를 예약해야 합니다. 공식은 다음과 같습니다.
10 + (최대 동시 트랜잭션 수 x 7) = 필요한 최소 열린 커서
SQL 캐시 비활성화: Post 프로세스는 완료 후 닫히는 루틴 호출을 위해 10개의 커서와 트랜잭션당 최소 2개의 커서를 예약해야 합니다. 공식은 다음과 같습니다.
10 + (최대 동시 트랜잭션 수 x 2) = 필요한 최소 열린 커서
유지 보수 DML 건너뛰기
대규모 유지 보수 트랜잭션 건너뛰기
유효 항목: Oracle 타겟
애플리케이션 패치 또는 기타 내부 Oracle 작업에 의해 적용되는 대규모 트랜잭션은 사용자 애플리케이션에 필요한 데이터와 관련이 없는 경우 복제에서 생략될 수 있습니다. 이러한 작업은 SharePlex에 대한 수천 개의 혹은 수백만 개의 개별 UPDATE 또는 DELETE 문으로 변환될 수 있으며 모두 Post에 의해 적용됩니다. 이 트랜잭션은 Post 성능에 부정적인 영향을 미칠 수 있으며 사용자 애플리케이션이 작업을 수행하는 데 필요한 소스 데이터와 타겟 데이터 간의 지연 시간을 증가시킬 수 있습니다. 다른 DML 작업이 타겟 데이터베이스에 게시되지 않도록 해야 하는 이유가 있을 수 있습니다.
이러한 트랜잭션을 처리할 수 있는 방법에는 두 가지가 있습니다.
- 해당 작업과 사용자 데이터 사이에 참조 관계가 없다고 가정하고, 해당 작업이 명명된 전용 Post 큐를 통해 처리되도록 구성합니다. 자세한 내용은 명명된 Post 큐 구성를 참조하십시오.
- 작업을 건너뛰도록 Post를 구성한 다음, Oracle을 통해 직접 SQL 문을 적용합니다. 다음 지침을 참조하십시오.
유지 보수 DML을 건너뛰려면 다음을 수행합니다.
- 소스 시스템에서 SharePlex product 디렉토리의 util 하위 디렉토리에서 create_ignore.sql 스크립트를 실행합니다. 이 스크립트는 데이터베이스에 SHAREPLEX_IGNORE_TRANS 공용 프로시저를 생성합니다. 트랜잭션 시작 시 프로시저가 실행되면 트랜잭션이 커밋되거나 롤백될 때까지 발생하는 DML 작업을 무시하도록 Capture 프로세스에 지시합니다. 따라서 영향을 받는 작업이 복제되지 않습니다. 스크립트, 제한 사항 및 실행 방법에 대한 자세한 내용은 SharePlex 참조 안내서의 create_ignore.sql을 참조하십시오.
- UPDATE 또는 DELETE 작업 전에 SHAREPLEX_IGNORE_TRANS를 호출하도록 패치 스크립트를 편집합니다. 이를 통해 SharePlex는 트랜잭션을 무시하고 타겟으로 보내지 않을 수 있습니다. 또한 데이터베이스를 재동기화하려면 타겟에서 스크립트를 실행해야 합니다.
참고: DML 작업만 SHAREPLEX_IGNORE_TRANS 프로시저의 영향을 받습니다. SharePlex가 TRUNCATE를 포함한 DDL 작업을 건너뛰지 않습니다. DDL 작업은 Oracle에 의해 암시적으로 커밋되므로 프로시저가 무효화됩니다.
