docwiki 번역 체인지 뷰스 (Change Views) 사용을 시작하기

[Kori]

Docwiki에 있는 "Getting Started with Change Views"을 번역한 글(최종 번역일: 2022년 8월 18일)

<< 위로 가기: 체인지 뷰스 (Change Views)

목차

1 ODS 플랫폼 업데이트

2 마이그레이션 이슈와 의존성 (Migration Issues and Dependencies)

3 요구사항과 제약조건 (Requirements and Constraints)

3.1 요구사항 (Requirements)

3.2 제약조건 (Constraints)

3.3 백업(Backup)/복구(Restore) 고려 사항

3.4 지연된 제약조건 확인 (Deferred Constraint Checking)

3.5 트리거 비활성화 (Trigger Inactivation)

3.6 백업를 가지고 데이터베이스 복구 (Database Restore from a Backup)

4 다음 단계 (Advance To)

---

1 ODS 플랫폼 업데이트

체인지 뷰스 (Change Views)를 위해서는 해당 인터베이스 데이터베이스 파일의 기반인 ODS가 맞아야 한다. 따라서 기존에 사용하던 데이터베이스인 경우에는 반드시 백업하고 알맞은  ODS 버전으로 복구해야만 이 기능을 사용할 수 있다. 복구된 데이터베이스에 새 ODS 포맷이 반영되고 나면 해당 데이터베이스를 더이상으로 이전 버전의 인터베이스에 붙이지 못한다.

2 마이그레이션 이슈와 의존성 (Migration Issues and Dependencies)

FOR ROW (..., DELETE)가 정의된 구독(subscription)인 경우, 삭제(delete)된 행도 반환된다. 여기에는 삭제 전에 컬럼(들)에 있던 값들이 제공된다. 존재하는 데이터를 제시하는 리포팅 애플리케이션에서는 삭제가 정의된 구독이 해당 트랜잭션에 묶이지 않도록 주의해야 한다. 이 경우에는, 더 이상 존재하지 않는 데이터(들) 까지도 포함되어 결과세트(resultset)로 반환된다.  

3 요구사항과 제약조건 (Requirements and Constraints)

3.1 요구사항 (Requirements)

• 체인지 뷰스 (Change Views)로 작업할 때 "홀수 번호 (odd-numbered)" SQL DATA TYPES(SQLVAR 변수, sqltype)를 사용해야 한다. 이렇게 하면 반환된 컬럼(column) 데이터에 대한 상태를 SQLVAR 안에 있는 SQL 표시기 변수에서  받을 수 있다.
• 체인지 뷰스 (Change Views)에서 데이터를 조회(select)할 때에는 트랜잭션 격리 수준 중 SNAPSHOT을 사용해야 한다. 체인지 뷰스 (Change Views)에서 데이터를 수정할 때에는 어떤 격리 수준이든 사용할 수 있다.
• 인터베이스의 테이블은 레코드 포맷의 버전을 최대 256개까지 가질 수 있다. 구독 하나가 테이블 하나를 참조하게 되면 해당 테이블에 새 레코드 포맷이 생긴다. CREATE SUBSCRIPTION 진술을 많이 만들 때에는 자동커밋(autocommit) DDL 동작을 비활성화하도록 하면 좋다. 그러면 많은 구독(들)이 여러 데이블을 참조할 때 레코드 포맷이 하나만 만들어진다.

3.2 제약조건 (Constraints)

• TRANSACTION ID는 구독 타임스탬프(TIMESTAMP)를 얻기 위한 프록시(PROXY) 역할을 한다
  • 체인지 뷰스 (Change Views) 기능은 TRANSACTION ID에 크게 의존한다. TRANSACTION ID는 체인지 뷰스 (Change Views)에서 조회(select)가 발생한 마지막 타임스탬프를 관찰(observe)하는 프록시 역할을 하기 때문이다. 덕분에 변경된 데이터를 중복으로 다시 전송하지 않는다. 지금은, 커밋(commit)된 데이터의 TRANSACTION ID가 데이터베이스 백업에 저장되지 않는다. 따라서 백업을 사용하여 데이터베이스를 복구(restore)하면, TRANSACTION ID가 다시 0으로 지정된다. TRANSACTION ID는 32-비트 공간이므로 고객 사이트에서 사용하다보면 소진될 수도 있다. 그런 경우에는 데이터베이스를 백업하고 복구(restore)해야 한다.
  • TRANSACTION ID를 64-비트 (48-비트가 될 확률이 높다)로 전환하는 프로젝트를 한다면, 합리적인 수준의 시간 동안 TRANSACTION ID가 소진되지 않게 될 수 있을 것이다. 예를 들어 TRANSACTION ID가 48-비트가 된다면, 페이지 크기가 4KB인 데이터베이스가 10,000 tps(초당 트랜잭션) 이상을 100년 동안 지속적으로 실행할 수 있다. 이것은 데이터 변경 뷰(changed data view)들을 지원할 뿐만 아니라, 인터베이스 데이터베이스를 TRANSACTION ID 소진 때문에 백업/복구하는 상황도 완전히 없앨 수 있다.

3.3 백업(Backup)/복구(Restore) 고려 사항

• 논리 백업(logical backup)/복구는 모든 구독 정의 (subscription definition)를 백업하고 복구하지만, 이 구독을 사용하는 구독자(subscriber)들을 추적하는 데이터는 백업되지 않고 복구되지도 않는다. 구독자(subscriber)들은 새 (또는 복구된) 데이터베이스에서 각자 자신의 구독을 개시/활성화를 해야 한다.

3.4 지연된 제약조건 확인 (Deferred Constraint Checking)

• 체인지 뷰스(Change Views) 기능은 원본 데이터베이스 안에서 발생한 변경의 순서 (sequence 또는 order)를 획득(capture)하지 않는다. 이 진술(statement)은 테이블 하나 안에서 뿐만 아니라 서로 다른 여러 테이블에 걸쳐서 발생된 변경에서도 마찬가지로 똑같이 적용된다. 의사-컬럼(pseudo-column)인 RECORD_VERSION 또는 TRANSACTION_ID를 노출하고 해당 컬럼을 기준으로 정렬하는 방식으로 대충 변경 순서를 짐작할 수는 있다. 하지만 이렇게 짐작한 결과가 모든 사용 사례에서 언제나  정확한 순서를 알려준다고 확신해서는 안된다. 구독을 하나 또는 그 이상 사용하여 동기화 매커니즘을 구현하는 경우에는, 제약조건(constraint) 확인을 충족해야 하는데 그러기 위해서는 변경이 발생한 순서가 중요할 수 있다. 인터베이스는 제약조건 확인 시 IMMEDIATE 만을 지원한다. 인터베이스에서 DEFERRED 제약조건 확인을 지원해야 한다는 요구사항이 있다. 그래야 목적지(destination) 데이터베이스에서 다양한 제약조건이 작동되고 있는 경우에도 구독 변경을 문제없이 적용할 수 있다.

3.5 트리거 비활성화 (Trigger Inactivation)

• 인터베이스에서는 "기명 트리거(named trigger)"를 비활성화 하도록 선언할 수 있다. 구독된 변경 사항이 목적지(destination) 데이터베이스에 적용될 때 트리거가 발동하지 않도록 방지해야 하는 상황이 있을 수 있기 때문이다. 트리거 비활성화 여부는 애플리케이션에 따라 알맞게 결정하면 된다. 하지만 지금 언급하는 트리거 비활성화는 그 범위(scope)를 해당 데이터베이스 세션 하나로만 제한해야 한다. 인터베이스는 해당 트리거를 해당 데이터베이스에 연결하는 모든 데이터베이스 세션에서 비활성화 한다. 작동 범위 제한이 필요하다는 요구사항이 있다. 만약 구현된다면, 제약조건 지연 (Deferred Constraint)이 요구되는 것과 마찬가지 일 것이다.

3.6 백업를 가지고 데이터베이스 복구 (Database Restore from a Backup)

• 논리 백업 파일 (logical backup file) 또는 물리적 덤프(dump) 파일을 사용하여 데이터베이스를 복구하면, 구독자(subscriber)들은 이미 받은 구독 변경 사항을 되찾을 수 있다.구독자는 RDB$SUBSCRIPTIONS.RDB$CHECK_OUT_TIMESTAMP 메타데이터를 저장할 수 있어서 변경이 중복으로 처리되는 이슈가 있을 때 도움을 받을 수 있다.

4 다음 단계 (Advance To)

• 체인지 뷰스에서 구독 생성하기 (Creating Subscriptions to Change Views)