동기화 대상 테이블 생성 및 등록

ProSync에서 테이블을 동기화하기 전에, 먼저 지원되는 데이터 타입을 확인한다. Source DB에 따라 지원하는 컬럼 타입이 다르므로 주의한다.

지원 데이터 타입

구분	지원 타입
Tibero	VARCHAR2, NVARCHAR2, NUMBER, FLOAT, LONG, DATE, BINARY_FLOAT, BINARY_DOUBLE, TIMESTAMP, TIMESTAMP WITH TIME ZONE, TIMESTAMP WITH LOCAL TIME ZONE, INTERVAL YEAR TO MONTH, INTERVAL DAY TO SECOND, RAW, CHAR, NCHAR, CLOB, NCLOB, BLOB, XMLTYPE
Oracle	VARCHAR2, NVARCHAR2, NUMBER, FLOAT, LONG, DATE, BINARY_FLOAT, BINARY_DOUBLE, TIMESTAMP, TIMESTAMP WITH TIME ZONE, TIMESTAMP WITH LOCAL TIME ZONE, INTERVAL YEAR TO MONTH, INTERVAL DAY TO SECOND, RAW, CHAR, NCHAR, CLOB, NCLOB, BLOB, XMLTYPE
PostgreSQL	CHAR, VARCHAR, INT, SMALLINT, BIGINT, DECIMAL, REAL, DOUBLE PRECISION, BYTEA, TEXT, DATE, TIMESTAMP

참고

• GEOMETRY 컬럼 타입은 Tibero to Tibero 동기화만 지원된다.

• CLOB, BLOB 컬럼의 경우, Target PostgreSQL의 OID 컬럼에 저장할 수 있으며 MAPPING RULE에 LARGEOBJECT 설정이 필요하다.

주의

서로 다른 Character Set 간의 데이터 처리

• Source DB와 Target DB의 Character Set이 다른 경우, ProSync 제품 내부에서 자동으로 Character Set을 Target DB Character Set에 맞게 변환하여 데이터를 삽입한다.

• 단, Source DB에서 지원하는 Character Set의 범위가 Target DB에서 지원하는 Character Set의 범위보다 넓을 경우, 변환 과정에서 Target DB에서 표현할 수 없는 문자가 발생할 수 있으며, 이 경우 해당 데이터는 깨지거나 손실될 수 있다.

• 따라서 이와 같은 문제를 방지하기 위해서는 양쪽 DB의 Character Set 호환성을 사전에 검토하고, 필요 시 Target DB의 Character Set을 상위 호환되는 문자 집합으로 설정하는 것이 권장된다.

IDENTITY COLUMN

IDENTITY COLUMN의 경우 ALWAYS 옵션을 사용하면 동기화가 불가능하다. 그 외 BY DEFAULT, BY DEFAULT ON NULL 옵션의 경우 동기화가 가능하지만, target의 identity 칼럼 sequence를 사용하지 않고 source에 저장된 값을 동기화한다.

Oracle 확장 데이터 타입

ProSync 4.7은 Oracle 확장 데이터 타입을 자동으로 인식한다. 컬럼의 선언 길이를 바이트 기준으로 확인하며, VARCHAR2·NVARCHAR2는 4,000바이트 초과, RAW는 2,000바이트 초과인 컬럼을 확장 타입으로 처리한다. USE_ORACLE_EXTENDED_TYPE 파라미터는 사용하지 않는다.

확장 타입 컬럼이 있는 소스 테이블에는 PRIMARY KEY가 필요하며, UNIQUE 제약조건이나 ROWID로 대신할 수 없다. 별도로 저장된 확장 값은 Llob 프로세스가 소스 DB에 Flashback Query를 수행하여 읽는다.

Llob 프로세스의 동작은 Llob Process를 참고한다.

ALTER MODIFY로 기존 컬럼의 길이를 확장한 뒤, 큰 값이 chained row 형태로 기록되어 로그 리더가 조각을 병합하지 못하는 변경은 지원하지 않는다. 이 경우 Extract가 경고 로그를 남기고 해당 변경을 건너뛴다.

---

테이블 생성

동기화 대상 테이블은 Source DB와 Target DB 각각에 존재해야 한다. MAP Rule을 사용하지 않는 기본 구성에서는 Source와 Target에 동일한 사용자 계정과 동일한 스키마 구조로 생성하는 것을 전제로 한다.

참고

Source와 다른 database/owner/table/column으로 반영해야 하는 경우에는 MAP Rule을 설정하여 매핑할 수 있다. 자세한 내용은 운영 가이드의 MAP Rule 설명을 참고한다.

다음은 TEST 사용자 계정에 테이블 T1, T2, T3을 생성하는 예제이다. Source DB와 Target DB 모두에 수행한다.

$ tbsql sys/password

SQL> CREATE USER TEST IDENTIFIED BY PASSWORD;
SQL> GRANT RESOURCE, CONNECT TO TEST;

SQL> CREATE TABLE TEST.T1 (C1 NUMBER PRIMARY KEY, C2 VARCHAR(10));
SQL> CREATE TABLE TEST.T2 (C1 NUMBER PRIMARY KEY, C2 VARCHAR(10));
SQL> CREATE TABLE TEST.T3 (C1 NUMBER PRIMARY KEY, C2 VARCHAR(10));

---

테이블 등록

동기화 대상 테이블은 아래 경로의 파일에 등록한다.

$PRS_HOME/install/prs_obj_group1.list

등록 형식은 OWNER_NAME.TABLE_NAME 형태로 작성한다.

#으로 시작하는 줄과 빈 줄은 무시된다. 그 외의 줄은 OWNER_NAME.TABLE_NAME 형식이어야 하며, 구분자 .가 없거나 둘 이상이거나 OWNER 또는 TABLE이 비어 있으면 잘못된 항목으로 판단해 설치를 중단한다.

특정 테이블 등록 예시

TEST.T1
TEST.T2
TEST.T3

참고

prs_obj_group#.list 파일 내의 OWNER_NAME과 TABLE_NAME은 대소문자를 구분한다.

와일드카드 등록

동기화 대상을 지정할 때 Table명과 User(Owner)명 모두에 % 와일드카드를 사용할 수 있다.

지정 예시	대상
TEST.%	TEST 소유의 모든 테이블 (Table 와일드카드)
TEST.TB%	TEST 소유의 테이블 중 이름이 TB로 시작하는 테이블
TEST%.%	이름이 TEST로 시작하는 모든 소유자의 모든 테이블 (User 와일드카드)
%.%	Source DB의 모든 소유자의 모든 테이블 (User 와일드카드)

사용 예시는 다음과 같다.

TEST.%
TEST%.%
%.%

자동으로 제외되는 대상

Source DB가 Tibero 또는 Oracle인 경우, 다음 객체는 동기화 대상에서 자동으로 제외된다. 제외 대상에 따라 적용 범위가 다르다.

제외 대상	적용 범위	설명
시스템 스키마의 객체	OWNER를 %가 포함된 패턴으로 지정한 경우에만	Oracle 12c 이상은 DB가 관리하는 계정(ALL_USERS.ORACLE_MAINTAINED = 'Y', SYS · SYSTEM 등)이 제외된다. Oracle 11g는 이 컬럼이 없으므로 Oracle 기본 계정과 옵션 계정의 고정 목록(SYS, SYSTEM, OUTLN, DBSNMP, DIP, ORACLE_OCM, APPQOSSYS, ANONYMOUS, XS$NULL, XDB, CTXSYS, MDSYS, MDDATA, ORDSYS, ORDDATA, ORDPLUGINS, SI_INFORMTN_SCHEMA, OLAPSYS, EXFSYS, WMSYS, SYSMAN, MGMT_VIEW, OWBSYS, OWBSYS_AUDIT, SPATIAL_CSW_ADMIN_USR, SPATIAL_WFS_ADMIN_USR, TSMSYS, DMSYS, WKSYS, WKPROXY, WK_TEST, LBACSYS, DVSYS, DVF, FLOWS_FILES, APEX_PUBLIC_USER)과, APEX_030200 · FLOWS_030000처럼 APEX_ 또는 FLOWS_ 뒤에 숫자 6자리가 붙는 계정이 제외되며, 목록에 없는 계정은 제외되지 않는다. Tibero는 SYS, SYSCAT, SYSGIS, OUTLN, LBACSYS 및 일반 사용자가 아닌 계정이 제외된다.
ProSync 운영 계정과 메타 객체	항상	PRS_USER 소유의 객체와 PRS_OBJ_LIST, PRS_DD_*, PRS_LCT 등 ProSync가 생성한 메타 객체가 제외된다.
AQ 관련 테이블	항상	이름이 AQ$_ 로 시작하는 테이블이 제외된다.
IOT overflow 세그먼트	항상	이름이 SYS_IOT_OVER_ 로 시작하는 테이블이 제외된다.
Recycle Bin 객체	항상	이름이 BIN$ 로 시작하는 객체가 제외된다.

또한 등록되는 객체 타입은 TABLE과 SEQUENCE로 한정되며, 그 외의 객체 타입은 등록되지 않는다.

주의 — OWNER를 이름으로 명시한 경우

시스템 스키마 제외는 %.%, TEST%.%처럼 OWNER에 %를 사용해 여러 스키마를 한 번에 지정할 때만 적용된다. TEST.%처럼 OWNER를 이름으로 명시하면 적용되지 않으며, 지정한 스키마의 객체가 그대로 등록된다.

Oracle CDB 환경에서 C## 접두어 없이 만든 계정이나 ALTER SESSION SET "_ORACLE_SCRIPT"=TRUE를 사용해 만든 계정은 ALL_USERS.ORACLE_MAINTAINED가 'Y'로 표시된다. 이런 계정도 OWNER로 명시하면 동기화 대상으로 등록된다.

참고

위의 자동 제외는 prs_obj_group#.list를 처리하는 설치 과정에 적용된다. Admin 명령으로 테이블을 직접 등록할 때는 적용되지 않는다.

Source DB가 PostgreSQL인 경우에도 위의 자동 제외가 적용되지 않으며 일반 테이블과 파티션 테이블만 등록된다. 와일드카드로 지정할 때는 시스템 스키마가 포함되지 않도록 소유자 패턴을 명시적으로 지정한다.

주의 — 와일드카드 사용과 Instance 구성

와일드카드로 동기화 대상을 지정하면 다른 Instance가 동기화하고 있는 테이블까지 대상에 포함될 수 있으며, 이 경우 같은 테이블이 여러 Instance를 통해 중복으로 동기화된다.

특히 User 와일드카드(%.%, TEST%.%)는 Table 와일드카드보다 범위가 넓어 다른 소유자의 테이블까지 한번에 포함하므로, User 와일드카드를 사용하는 경우 단일 Instance로 구성할 것을 권장한다.

Table 와일드카드(TEST.%)를 사용하는 경우에도 동일한 문제가 발생할 수 있으므로, 다중 Instance 환경에서는 Instance별 동기화 대상이 서로 겹치지 않는지 확인한 뒤 사용한다.

주의 — 동기화 대상이 등록되지 않은 경우

prs_obj_group#.list의 어떤 항목도 실제 객체를 찾지 못하면 설치가 실패로 종료된다.

설치 과정에서 항목별로 조회 결과가 0건이면 * warning: no object matched [TEST.%] - nothing registered for this entry 형태의 경고를 출력하고, 등록된 동기화 대상이 하나도 없으면 Checking registered sync objects... none registered를 출력하며 설치를 중단한다.

OWNER와 TABLE 이름의 대소문자가 맞는지, 그리고 해당 객체가 설치 시점에 Source DB에 이미 존재하는지 확인한 뒤 다시 설치한다.

주의

prs_obj_group#.list 파일은 설치 시점에만 처리되어 Source의 동기화 대상 목록(PRS_OBJ_LIST)을 구성하는 데 사용된다. 설치 이후에 이 파일만 수정하는 것으로는 운영 중인 인스턴스에 반영되지 않는다.

설치 이후에 생성한 테이블을 동기화 대상에 추가하려면 아래의 '동기화 대상 자동 등록'을 사용하거나, Admin 명령 ALTER <instance> ADD TABLE <owner>.<table> GROUP=<n>으로 등록한다. 수동으로 등록하는 경우 Tibero/Oracle은 해당 테이블의 supplemental logging 설정을, PostgreSQL은 replica identity 및 publication 설정을 함께 확인해야 한다.

---

동기화 대상 자동 등록

Source DB가 Tibero 또는 Oracle인 경우, 설치 config 파일에 AUTO_SYNC_ON_CREATE=Y를 설정하면 설치 이후 CREATE 문으로 생성된 테이블과 시퀀스가 자동으로 동기화 대상에 등록된다. prs_obj_group#.list에 미리 적지 못한 테이블을 매번 Admin 명령으로 등록하거나 재설치할 필요가 없다.

사전 준비 — DB 단위 Supplemental Log

자동 등록을 사용하려면 Source DB에 DB 단위 supplemental log가 설정되어 있어야 한다. 테이블 단위로만 supplemental log를 건 경우, 자동 등록된 테이블은 supplemental log가 없는 상태가 되어 변경분을 추출할 수 없다.

Source DB가 Oracle인 경우 DB 단위로 supplemental log를 설정한다. 설치 config 파일에 SUPP_LOG_LVL_ALL=Y를 설정하면 설치 과정에서 database level로 설정된다.

SQL> ALTER DATABASE ADD SUPPLEMENTAL LOG DATA (ALL) COLUMNS;

Source DB가 Tibero인 경우 _DDL_AUTO_SUPPLOG_CTBL을 TRUE로 설정하여 DB 단위 supplemental log를 활성화한다. 운영 중인 DB에는 ALTER SYSTEM으로 바로 적용할 수 있으나 이 변경은 DB 재기동 후 유지되지 않으므로, TIP 파일에도 같은 값을 설정한다. TAC 환경에서는 모든 노드에 동일하게 설정한다.

SQL> ALTER SYSTEM SET _DDL_AUTO_SUPPLOG_CTBL=TRUE;

_DDL_AUTO_SUPPLOG_CTBL=TRUE

설치 config 파일에 AUTO_SYNC_ON_CREATE=Y를 설정하면 설치 과정에서 이 값을 확인하며, 설정되어 있지 않으면 안내 메시지와 함께 설치를 중단한다.

설정 예시

# Source Tibero
SRC_DB_TYPE=TIBERO
SRC_DB_NAME=src_tibero
AUTO_SYNC_ON_CREATE=Y

# Source Oracle
SRC_DB_TYPE=ORACLE
SRC_DB_NAME=src_oracle
AUTO_SYNC_ON_CREATE=Y
SUPP_LOG_LVL_ALL=Y

주의

자동 등록은 Source DB의 동기화 대상 목록에 등록하는 것까지를 수행한다. Target DB에 동일한 테이블이 없으면 반영 단계에서 실패하므로, CREATE TABLE에 대한 DDL 동기화를 함께 구성하거나 Target DB에 테이블을 미리 생성해야 한다.

또한 자동 등록은 대상을 가리지 않고 생성되는 모든 테이블과 시퀀스를 등록하므로 다른 Instance의 동기화 대상과 중복될 수 있다. 와일드카드 등록과 마찬가지로 단일 Instance 구성에서 사용할 것을 권장하며, 동기화하지 않아야 할 객체가 생성되는 환경에서는 사용에 유의한다.