ADD HEARTBEATTABLE

지원되는 모든 데이터베이스의 경우 적합합니다. 지원되는 데이터베이스에 대한 자세한 내용은 인증 매트릭스를 참조하십시오.

이 명령을 사용하려면 DBLOGIN으로 데이터베이스에 로그인해야 있습니다.

ADD HEARTBEATTABLE을 사용하여 자동 Heartbeat 기능 사용에 필요한 객체를 생성할 수 있다. 이 명령은 다음 작업을 수행합니다.

Heartbeat 시드 테이블, Heartbeat 테이블 및 Heartbeat 내역 테이블을 생성합니다.
GG_LAG 및 GG_LAG_HISTORY 뷰를 생성합니다.
스케줄러 작업에 의해 호출되는 GG_UPDATE_HB_TAB 및 GG_PURGE_HB_TAB 프로시저를 생성합니다.
주기적으로 Heartbeat 및 시드 테이블을 업데이트하고 내역 테이블을 비우는 스케줄러 작업을 생성합니다. 단, Azure SQL Database, PostgreSQL, Teradata 및 TimesTen의 경우 해당 작업이 생성되지 않습니다.
시드 테이블을 채웁니다.
Oracle 다중 테넌트 데이터베이스의 경우:
- Heartbeat 객체와 작업은 DBLOGIN 명령을 사용하여 데이터베이스에 접속된 사용자의 스키마에 생성됩니다. Oracle GoldenGate Extract 및 Replicat는 USERID 또는 USERIDALIAS 스키마에서 하트비트 객체를 찾습니다. DBLOGIN을 사용하여 접속하는 경우 Extract 및 Replicat 프로세스에서 사용할 적절한 USERID 또는 USERIDALIAS 스키마로 설정되어 있는지 확인합니다.
- Extract: 각 PDB에서 스키마 이름을 사용합니다. Extract가 등록된 각 PDB에는 고유 Heartbeat 테이블이 있어야 합니다.
- Replicat: 각 Replicat에는 해당 PDB에 대한 고유 Heartbeat 테이블이 있어야 합니다.
- 양방향 활성/활성 복제의 경우 Heartbeat 테이블은 각 사이트에서 송신 Extract 및 수신 Replicat에 대해 동일한 스키마에 있어야 합니다. 예를 들어, 다음 사용 사례를 참조하십시오.
  
  Site A Site B
  
  EAB ————> ` RAB`
  
  RBA ————> ` EBA`
  
  이 예에서는 EAB 및 RBA Heartbeat 테이블이 동일한 스키마를 사용해야 합니다. 단, EAB 및 RAB는 다른 스키마를 사용할 수 있습니다.

제한된 상황을 제외하고는 GGSCHEMA(또는 HEARTBEATTABLE 매개변수)가 필요하지 않도록 함으로써 Oracle Heartbeat 테이블 관리를 위해 Oracle GoldenGate가 간소화되었습니다. Heartbeat 테이블 관리 작업은 DBLOGIN 사용자의 스키마에서만 수행됩니다. Oracle CDB 루트 Extract를 제외하고 Extract 및 Replicat 프로세스는 ER에 접속된 사용자의 스키마에서 Heartbeat 테이블을 찾습니다. 다음 표에서는 Oracle AI Database에 대한 Extract 및 Replicat 동작을 보여줍니다.

Extract/Replicat 프로세스	동작
비루트 Extract(비CDB 및 PDB)	첫번째 Extract 사용자인 경우 `GGSCHEMA`가 사용되고, 자율운영 AI 데이터베이스의 경우 사용자는 `ggadmin`이어야 합니다. Extract가 시작된 후 Heartbeat가 생성되면 Extract 사용자에서만 찾습니다.
CDB 루트 Extract	`GGSCHEMA`가 사용됩니다.
Replicat	첫번째 Replicat 사용자인 경우 `GGSCHEMA`가 사용됩니다. ADB의 경우 사용자는 `ggadmin`이어야 합니다. Replicat가 시작된 후 Heartbeat가 생성되면 Replicat 사용자에서만 찾습니다.
`DELETE EXTRACT/REPLICAT`	첫번째 Extract 또는 Replicat 사용자인 경우 `GGSCHEMA`가 사용됩니다. ADB의 경우 사용자는 `ggadmin`이어야 합니다.

이 기능을 사용하면 여러 데이터베이스가 서로 다른 Oracle GoldenGate 관리자 스키마로 관리되는 Oracle GoldenGate 허브 배치에서 Heartbeat 테이블을 사용할 수 있습니다.

주: Heartbeat 테이블 객체는 Oracle Multitenant 데이터베이스의 루트 CDB에 생성되지 않아야 합니다.

이기종 또는 비Oracle 데이터베이스의 경우 하트비트 객체 및 작업은 GLOBALS 파일에 나열된 GGSCHEMA 값에 생성됩니다.

기본 시드, Heartbeat 및 내역 테이블 이름은 각각 GG_HEARTBEAT_SEED, GG_HEARTBEAT 및 GG_HEARTBEAT_HISTORY입니다.

마이크로 서비스 아키텍처에서 스키마는 복제 설정을 사용하여 구성됩니다.

GLOBALS 파일에서 HEARTBEATTABLE hbschemaname.hbtablename을 지정하여 기본 이름을 무효화할 수 있습니다.
테이블, 프로시저 및 작업이 hbschemaname 스키마에서 생성됩니다.
_SEED 및 _HISTORY를 테이블에 hbtablename를 추가하여 시드와 내역 테이블이 생성됩니다.

Db2 LUW의 경우 db2set DB2_ATS_ENABLE=yes 명령으로 DB2_ATS_ENABLE 속성을 설정해야 합니다.

For Db2 for i, to handle upgrade or misconfiguration of heartbeat table functionality, you can run the ADD HEARTBEATTABLE command again, which will repair the functionality of an exisiting heartbeattable setup without deleting the existing heartbeat data.

i용 Db2의 경우 라이선스가 있는 프로그램인 5770SS1 Option 39 International Components for Unicode를 설치해야 합니다.

Db2 for i의 경우 Heartbeat 테이블은 해당 Heartbeat 테이블을 사용하여 Extract에서 복제되는 객체와 동일한 저널에 저널링되어야 합니다. 그렇지 않은 경우 Extract는 두 개 이상의 저널을 사용할 수 있음을 나타내며 비정상 종료됩니다. 또한 동일한 저널을 읽지 않는 특정 Oracle GoldenGate 설치의 다른 Extract에서는 Heartbeat 테이블이 사용으로 설정될 수 없습니다.

Amazon Aurora MySQL의 경우 전역 변수 event_scheduler를 매개변수 그룹에서 사용으로 설정해야 합니다. Amazon RDS가 전역 변수 설정을 허용하지 않기 때문입니다. 데이터베이스가 재시작되면 event_scheduler가 사용 안함 상태로 돌아갑니다. 이를 방지하려면 my.cnf/ini 파일에서 event_scheduler를 사용으로 설정해야 합니다.

PostgreSQL의 경우 하트비트 레코드 업데이트 및 내역 레코드 비우기 함수인 gg_hb_job_run을 주기적으로 호출하려면 시스템 작업을 수동으로 생성해야 합니다. 예를 들어, 매 분 실행되는 cron 작업을 생성할 수 있습니다. 이 함수는 Heartbeat 구성의 실제 Heartbeat 레코드 업데이트 및 비우기 빈도 설정을 확인하고 해당 경계 내의 작업만 처리합니다.

PGPASSWORD="$passwd" psql -U gguser -d dbname -h dbhostname -p dbport# -c "select <ggschema.gg_hb_job_run();" >/dev/null 2>&1

Azure SQL Database의 경우 ADD HEARTBEATTABLE TARGETONLY만 지원됩니다. Azure SQL Database를 사용하는 SQL Server Agent가 없으므로 비우기 루틴을 생성할 수 없습니다. 따라서 이전 heartbeat 레코드를 제거하려는 사용자는 GG_PURGE_HB_TAB 내장 프로시저를 주기적으로 실행해야 합니다.

구문

ADD HEARTBEATTABLE
[, FREQUENCY number_in_seconds]
[, RETENTION_TIME number_in_days] |
[, PURGE_FREQUENCY number_in_days]
[, PARTITIONED]
[, TARGETONLY]

FREQUENCY number_in_seconds

Heartbeat 레코드 생성 빈도를 지정합니다. 기본값은 60초입니다.

다음 제한 사항을 고려하십시오.

Oracle AI Database의 경우 최소값은 0이며 최대값은 7999입니다.
Db2 for i Series의 경우 최소값은 0이며 최대값은 7999입니다.
Db2 LUW 및 Db2 z/OS의 경우 최소값은 60이며 최대값은 7999입니다.
Db2/zOS 및 Db2 LUW에 대한 빈도는 3600보다 작은 값의 경우 60의 배수이고, 3600보다 크거나 같은 값의 경우 3600의 배수여야 합니다.
MySQL의 경우 최소값은 0이며 최대값은 7999입니다.
SQL Server의 경우 최소값은 10이며 최대값은 7999입니다.
PostgreSQL의 경우 최소값은 60이며 최대값은 7999입니다.
Sybase의 경우 최소값은 1분(60초)이고 최대값은 133분(7999초)입니다.
FREQUENCY를 0으로 지정할 수 있도록 지원하는 데이터베이스는 heartbeat 레코드 스케줄러를 일시 정지합니다.

RETENTION_TIME number_in_days

Heartbeat 내역 테이블의 보존 시간보다 오래된 Heartbeat 항목이 비워지도록 지정합니다. 기본값은 30일입니다.

모든 데이터베이스에 대한 최소값은 1이며 최대값은 2147483646입니다.

PURGE_FREQUENCY number_in_days

비우기 스케줄러가 Heartbeat 내역 테이블에서 보존 시간보다 오래된 테이블 항목을 삭제하도록 실행되는 빈도를 지정합니다. 기본값은 1일입니다.

Db2 LUW 및 Db2 z/OS의 경우 최소값은 1이며 최대값은 31입니다.

기타 지원되는 모든 데이터베이스의 경우 최소값은 1이며 최대값은 199입니다.

PARTITIONED

Oracle의 경우 적합합니다.

Heartbeat 내역 테이블에서 분할을 사용으로 설정합니다. 수신된 Heartbeat 시간기록 열은 1일 간격으로 테이블을 분할하는 데 사용됩니다. 기본적으로 Heartbeat 내역 테이블은 분할되어 있지 않습니다.

TARGETONLY

Oracle AI Database, Db2 i Series, Db2 LUW, Db2 z/OS, MySQL, PostgreSQL 및 SQL Server에 적합합니다.

Heartbeat 시드 테이블과 Heartbeat 테이블에서 동시에 보완 로깅을 사용으로 설정하지 마십시오. Heartbeat 테이블 업데이트를 위한 스케줄러 작업이 생성되지 않습니다.

예제

다음 명령은 기본 Heartbeat 테이블, 프로시저 및 작업을 생성합니다.

ADD HEARTBEATTABLE

다음 명령은 사용자정의 빈도, 보존 시간 및 비우기 빈도를 사용하여 Heartbeat 테이블, 프로시저 및 작업을 생성합니다.

ADD HEARTBEATTABLE, FREQUENCY 120, RETENTION_TIME 10, PURGE_FREQUENCY 2

다음 명령은 Heartbeat 내역 테이블에서 분할이 사용으로 설정된 Heartbeat 테이블, 프로시저 및 작업을 생성하며, Heartbeat 및 Heartbeat 시드 테이블에서 보완 로깅이 사용으로 설정되지 않습니다.

ADD HEARTBEATTABLE, partitioned, TARGETONLY