Kori 8월 18일, 2022에 포스트됨 공유하기 8월 18일, 2022에 포스트됨 Docwiki에 있는 "Creating Subscriptions to Change Views"를 번역한 글(최종 번역일: 2022년 8월 18일) << 위로 가기: 체인지 뷰스 (Change Views) 데이터베이스 연결(connection)의 자연스러운 경계를 넘어서 테이블(들)을 한(1) 세트를 대상으로 변경된 데이터를 관찰(observe)하려면, 반드시 구독 하나를 생성하고 이 구독에 해당 테이블(기반 테이블 또는 뷰)들을 나열해야 한다. CREATE SUBSCRIPTION 문장 구성(Syntax) CREATE SUBSCRIPTION <구독_이름> ON< <테이블_이름>[(필요한 컬럼들을 쉼표로 구분하여 나열)][FOR ROW (CHANGE | {INSERT, UPDATE, DELETE})] [,<테이블_이름>[(필요한 컬럼들을 쉼표로 구분하여 나열)][FOR ROW (CHANGE | {INSERT, UPDATE, DELETE})] ...] [DESCRIPTION 사용자를 위한 설명]; FOR ROW 절은 해당 구독에서 어떤 변경 유형에 대해서 컬럼-수준 변경 추적을 할 것인지를 지정한다. FOR ROW 절을 생략하면 기본 설정인 FOR ROW (CHANGE)로 작동한다. CHANGE 옵션은 INSERT와 UPDATE 데이터 변경 동작을 추적하고 추적 대상 컬럼 중 어느 하나라도 값이 변경하면 즉시 해당 행(row)을 반환한다. INSERT, UPDATE, DELETE를 명시하면, 변경 추적 대상 컬럼 모두에 해당 변경 상태가 지정된다. 이 옵션은 "깊은 레코드 검사(deep record introspection)"라고 부른다. CHANGE 옵션은 "얕은 레코드 검사(shallow record introspection)"라고 부른다. CHANGE 옵션은 보다 성능이 좋고 INSERT, UPDATE, DELETE가 모두 넣은 옵션은 보다 완전도가 높다. DELETE는 기본 설정에 해당되지 않으므로, 포함하려면 직접 명시해야 한다. "깊은 레코드 검사"는 추적 대상 컬럼 모두에 대해 해당 컬럼의 값을 변경 시킨 동작을 정확히 알아야 하는 경우에 필요하다. "얕은 레코드 검사"는 추적 대상 컬럼 중 어느 컬럼에서든 값 변경이 발생했는 지 그 여부만 알면 되고, 추적 대상 컬럼 "모두에 대해 각각" 무슨 동작에 의해 변경되었는 지 (또는 변경되지 않았는 지)를 알 필요가 없는 사용 사례인 경우에 사용할 수 있다. 즉, 해당 구독으로 관찰한 바에 따르면 해당 행(row)은 어떤 동작에 의해서든 변경되었다는 점을 알려준다. 테이블만 명시한 경우에는 해당 테이블의 모든 컬럼을 추적한다. 일부 컬럼(들)만 추적하고 싶은 경우에는 원하는 컬럼(들)을 나열하여 명시할 수 있다. 예를 들어, CREATE SUBSCRIPTION 예문 CREATE SUBSCRIPTION sub_employee_changes ON EMPLOYEE (EMP_NO, DEPT_NO, SALARY) DESCRIPTION 'EMPLOYEE 테이블 안에서 발생한 변경 구독'; CREATE SUBSCRIPTION sub_customer_deletes ON CUSTOMER FOR ROW (DELETE) DESCRIPTION 'CUSTOMER 테이블에서 발생한 삭제 구독'; CREATE SUBSCRIPTION sub_various_changes ON EMPLOYEE FOR ROW (INSERT, UPDATE, DELETE), CUSTOMER FOR ROW (INSERT, UPDATE, DELETE), SALES FOR ROW (UPDATE), DEPARTMENT (LOCATION) FOR ROW (UPDATE) DESCRIPTION '여러 테이블에서 발생한 여러 변경을 구독'; 특정 컬럼들을 목록으로 나열하는 것은 옵션 사항이다. 위 예제에서는 EMPLOYEE 테이블에 이 옵션을 적용하여 해당 컬럼들의 변경만 추적하도록 했다. 또한 EMPLOYEE 테이블에는 FOR ROW 절이 없기 때문에, 기본(default) FOR ROW 옵션인 CHANGE 옵션이 적용된다. CHANGE 옵션은 INSERT와 UPDATE 데이터 변경 동작을 추적하고 값이 변경된 모든 컬럼의 값을 담은 행(row)를 즉시 반환한다. CUSTOMER 테이블에는 FOR ROW 절에 DELETE가 명시되어 있기 때문에 행(row) 삭제 (delete)만 추적된다. 목차 1 DROP SUBSCRIPTION (구독 제거) 2 GRANT SUBSCRIBE (구독 권한 부여) 3 SET SUBSCRIPTION (구독 지정) 4 다음 단계 (Advance To) 1 DROP SUBSCRIPTION (구독 제거) 알아둘 점: 이 기능은 인터베이스 XE7 업데이트 1부터 제공된다. 변경 뷰(들)을 관찰하기(observe)를 완전히 그만하려면, 해당 구독(subscription)을 반드시 제거(drop) 해야 한다. RESTRICT를 명시하는 경우, 구독자(subscriber)가 있는 지 확인 동작이 수행된다. 만약 구독자가 있으면 에러가 반환되고 구독은 제거(drop)되지 않는다. CASCADE를 명시하는 경우, 해당 구독을 구독하는 모든 구독자가지 모두 제거(drop)된다. RESTRICT와 CASCADE 중 어느것도 명시하지 않으면, RESTRICT로 간주한다. DROP SUBSCRIPTION 문장 구성(Syntax) DROP SUBSCRIPTION <구독_이름> [RESTRICT | CASCADE]; 2 GRANT SUBSCRIBE (구독 권한 부여) 목록에 나열된 테이블 상의 변경을 사용자가 추적할 수 있도록 하려면, 그 사용자에게 해당 구독을 구독할 수 있는 SUBSCRIBE 특권(privilege)을 부여한다. GRANT SUBSCRIBE 문장 구성(Syntax) GRANT SUBSCRIBE ON SUBSCRIPTION <구독_이름> TO <사용자_이름>; REVOKE SUBSCRIBE ON SUBSCRIPTION <구독_이름> FROM <사용자_이름>; 3 SET SUBSCRIPTION (구독 지정) 구독(subscription)을 활성화(Active)로 지정하려면, 애플리케이션에서 SET SUBSCRIPTION 진술을 발행한다. SET SUBSCRIPTION 진술에서는 구독 여러개를 활성화할 수 있고 AT 절을 사용하여 구독한 변경을 수신하는 목적지 또는 장비의 이름을 명시한다. 구독자(subscriber)의 사용자 이름은 데이터베이스 연결에서 식별되는 사용자의 신원이라고 암묵적으로 이해될 수도 있다. 해당 사용자를 위한 동일한 스키마 오브젝트에 대한 여러 구독을 AT 절을 통해서 명시적으로 지정하는 것은 다음 두가지 동기에서 비롯되었다. 첫째, 사용자 한명은 여러 장비에서 구독을 받을 수 있는데 해당 장비들은 연결이 끊어질 수도 있어서 변경된 세트를 받기 위해 다른 시간에 다른 목적으로 독립적으로 필요한 구독을 조회할 수도 있다. 둘째, 몇몇 다중-사용자 (multiuser) 애플리케이션에서는 데이터베이스 연결 풀링을 사용하여 단일 사용자 이름(예: CRM_User 또는 심지어 SYSDBA) 만으로 데이터베이스를 연결한다. 이런 경우에, 구독은 변경 세트를 조회할 때 대체 식별자 ( alternate identifier)를 제공받아야만 어느 사용자를 위한 구독인 지를 구별할 수 있다. 이런 추가 식별자로는 목적지(destination) 즉 "장비 이름"의 식별자라고도 생각해 볼 수 있다. SET SUBSCRIPTION 진술은 구독자(subscriber)를 위해 구독을 활성화/비활성하여 해당 명령을 실행하는 트랜잭션에 구독(subscription)을 묶기(bind)/풀기(unbind)를 한다. 구독이 묶인 트랜잭션에 의해 실행되는 사용자-수준(user-level) 쿼리에서는 구독 대상 테이블(들)은 모두 해당 구독 안에서 변경 뷰(들)로 작동한다. 따라서 변경 뷰를 계속 원한다면, 이어지는 다른 트랜잭션들에서도 SET SUBSCRIPTION 를 발행해야 한다. 트랜잭션이 커밋(commit)되는 시점에는, 해당 구독자(subscriber)의 트랜잭션 상태가 업데이트 되어서 해당 구독자들이 해당 커밋 이전의 변경을 보지 않고 해당 커밋 이후에 발생된 변경들을 볼 수 있게 된다. 트랜잭션을 롤백(rollback)하면 해당 구독자의 트랜잭션 상태는 변경되지 않기 때문에 해당 변경 뷰는 여전히 롤백 이전의 변경을 계속 볼 수 있지만 롤백 이후의 새 변경을 보지는 못한다. 만약 구독이 묶여있는(bind) 트랜잭션이지만, 이 트랜잭션에서 구독의 추적 대상인 테이블 중에서 어느 하나도 읽지 않는다면 해당 구독의 해당 구독자 트랜잭션의 문맥은 업데이트 되지 않는다. SET SUBSCRIPTION 문장 구성과 예문 SET SUBSCRIPTION [<구독_이름> [, <구독_이름> ...]] [AT <목적지>] {ACTIVE | INACTIVE}; SET SUBSCRIPTION sub_employee_changes, sub_customer_deletes AT '스마트폰_123' ACTIVE; SELECT EMP_NO, DEPT_NO, SALARY FROM EMPLOYEE; SELECT * FROM CUSTOMER; COMMIT or COMMIT RETAIN; 이 예문은 구독 두(2)개를 활성화하고 구독의 추적 대상 테이블(들)에서 변경된 데이터를 반환한다. COMMIT은 해당 트랜잭션 동안 참조된 스키마 오브젝트(들)에 대한 모든 구독을 업데이트 하여 가장 마지막에 관찰(observe)된 타임스탬프(timestamp)와 트랜잭션 문맥(context)을 지정한다. COMMIT RETAIN은 가장 마지막 관찰 상태를 변경하지 않고 그대로 최신 스냅샷을 유지한다. 구독은 해당 트랜잭션이 커밋(COMMIT)될 때 풀린다. 구독이 풀린 이후에 구독 대상 스키마 오브젝트(들)에 대한 후속 쿼리(query)는 일반 데이터 세트를 반환한다. 즉 데이터 변경 상태와 관련이 없어진다. 트랜잭션 하나에서 동시에 활성할 수 있는 구독의 갯수에는 제한이 없다. 4 다음 단계 (Advance To) 진술 실행(Statement Execution) 인용하기 이 댓글 링크 다른 사이트에 공유하기 더 많은 공유 선택 사항
Recommended Posts
이 토의에 참여하세요
지금 바로 의견을 남길 수 있습니다. 그리고 나서 가입해도 됩니다. 이미 회원이라면, 지금 로그인하고 본인 계정으로 의견을 남기세요.