나는 테이블 마녀가 말 T1 (초당 약 100 업데이트, 약 300K 행)oracle의 예약 된 테이블 스냅 샷?
그리고 두 번째 테이블 T2에서 그들이 T1의 상태있어에 나는 기반으로, 행을 업데이 트하려는 않을까 강렬한 워크로드에있다 나는 그것이 트리거에 의해 쉽게 이루어질 수 있다는 것을 알고 있지만 시나리오에서 트리거는 성능에 엄청난 영향을 미치고 T1 성능은 초당 약 10 번의 업데이트로 감소합니다 ...
이제 임시 테이블 T3을 만들었고 그 중 하나를 선택했습니다 T1 상태, 그 후에 T3를 사용하여 T1에 병합합니다.
그러나 여전히 SELECT INTO 임시 테이블은 큰 비용입니다.
T1에서 업데이트 작업을 크게 줄이지 않고도 내 시나리오를 달성 할 수있는 방법이 있습니까?
일반적으로 T1의 데이터를 기반으로 T2를 정기적으로 업데이트하는 경우 매우 OLTP 유형 시스템처럼 들리지만 데이터 모델에 대한 질문이 있습니다. 그것은 저에게 정규화가 부족하다는 것을 의미합니다. T1에있는 일부 데이터를 복제하는 별도의 T2 테이블을 가지고있는 완벽한 이유가있을 수 있습니다 (예 : 정규화 된 개체를 사용하는 OLTP 유형 쿼리 외에도 비정규 화 된 개체로 DSS 유형 쿼리를 지원하려는 경우) 이 경우 T2의 비즈니스 목적을 이해하는 것이 유용 할 것입니다.
여러 개의 정규화 된 테이블의 데이터를 결합하는 비정규 화 된 객체로 DSS 유형 쿼리를 지원하려는 경우, 먼저 T2가 테이블이 아닌 구체화 된보기로 작성되는 것이 좋습니다. 구체화 된 뷰는 예약 된 간격으로 점진적으로 새로 고칠 수 있습니다 (변경 사항이 커밋 될 때 새로 고칠 수도 있지만 동기식으로 발생하므로 삽입 세션 속도가 느려질 수 있음). 기본 테이블에 구체화 된 뷰 로그가 있어야 DML 작업에 약간의 오버 헤드가 추가되지만, 특히 각 업데이트가 300-ish 행을 업데이트하는 경우 트리거의 오버 헤드보다 적습니다 (300k가 행은 초당 100 개의 업데이트로 업데이트됩니다.
스트림을 사용하여 T2를 유지 관리 할 수도 있습니다. 이는 Streams가 리두 데이터를 읽고 있기 때문에 기본적으로 DML 작업의 변경 사항을 추적하는 오버 헤드를 제거합니다. 보충 로깅이 아직 활성화되어 있지 않은 경우 보충 로깅을 활성화해야 할 수 있습니다. 보충 로깅은 재실행 할 데이터 양을 약간 증가시킬 수는 있지만 눈에 띄지는 않습니다. 그러나 Streams를 구성하는 데는 조금 더 많은 작업이 필요합니다. T1에서 변경 사항을 적용하고 T2를 업데이트하는 사용자 정의 적용 핸들러를 작성해야합니다. 그리고 T2는 항상 T1에서 적어도 몇 초 지연됩니다.
ㅎ, 제 영어가 그리 좋지 않아서 당신의 대답을 이해하지 못합니다. 그러나 시도 할 시간이 조금 걸릴 것입니다 : 그리고 300k는 행 수입니다 T1 테이블에서 업데이트는 항상 1 행에 영향을줍니다. 또한 T2 상태를 온라인으로 업데이트하지 않고 T1 상태의 5-10 분 지연을 수용 할 수 있습니다. – canni
@ canni- 원하는 모든 간격으로 구체화 된보기를 새로 고칠 수 있습니다. 따라서 5 분마다, 10 분마다 또는 적절한 간격으로 새로 고칠 수 있습니다. –
감사합니다. 구체화 된보기를 살펴 보겠습니다. – canni
변경된 데이터에 관심이 있고 트리거를 기록하지 않으려면 변경 데이터 캡처, 스트림 또는 골든 게이트를 살펴보십시오. 모든 것이 귀하에게 논리적 변경 레코드를 제시 할 수 있습니다. 이를 위해 리두 로그를 읽고 트리거를 사용하여 전경 프로세스를 방해하지 마십시오. 다른 옵션은 테이블을 잘 보면서 테이블을 다시 정렬 할 수 있는지 확인하는 것입니다. 테이블의 상당 부분을 히스토리 (정적)로 정의하자마자 더 많은 옵션을 가질 수 있습니다.
데이터의 신선도는 어떻습니까? –
제 생각에 T2 업데이트/매 5 분마다 충분합니다 – canni