Idealy, apply partitioning to soa-infra tables and purge it please.
Soa-infra data를 오랜 기간 동안 보관해야 한다면? soa-infra 테이블을 파티셔닝하고, 기간별로 삭제하는 것이 가장 이상적인 방법이다.
But some clients want to keep received payloads to reinitiate the faulted process to resolve unexpected system crash or make sure the guaranteed delivery between two different management team's responsibility, especially, politicians :-P. So, it is required to be desinged retention period of delivered queue or history tables.
하지만, 일부 고객들은 수신한 메시지를 보관하고 싶어 하는데 그 이유는 예기치 못했던 시스템 장애 시에 실패한 프로세스를 간단하게 재기동하거나 메시지를 올바르게 전달했다는 기록을 갖고 싶어하기 때문이다. 그래서 메시지 큐나 이력 테이블의 보관주기를 설계하고
데이타를 유지하려고 한다.
In the large SOA integrated system, it is frequently required to purge soa-infra to avoid tablespace growth. How to resolve unexpected new requirement to keep BEPL payload with limited soa-infra tablespace timely?
하지만 규모가 큰 SOA 통합 시스템에서는 DB가 비대해지는 것을 막기 위해 soa-infra에 대한 purge작업이 꼭 필요하다. 이러한 두 가지 요건을 모두 만족하면서 BPEL의 payload를 일정기간 유지할 수 있는 방법이 있을까?
My suggestion is to backup BPEL payloads from soa-infra as it is required.
Here's my design and sample backup SQL:
내가 제안하는 방법은 soa-infra 테이블에서 BPEL의 payload만을 추출하여 별도로 백업해 놓는 방법이다.
상세한 내용은 아래의 그림과 backup SQL을 참조하기 바란다.
INSERT /*+ append */ INTO exp_payload (
SELECT es.guid,
bi.ECID,
bi.CIKEY,
SensT.ONum,
Senst.rnum,
ad.bin bin,
xd.document document,
xd.DOCUMENT_TYPE document_type,
bi.cpst_inst_created_time created_time,
null updated_time,
bi.CREATION_DATE,
bi.MODIFY_DATE
FROM PRD_SOAINFRA.exp_source es,
PRD_SOAINFRA.cube_instance bi,
PRD_SOAINFRA.audit_details ad,
PRD_SOAINFRA.xml_document xd,
(SELECT composite_instance_id,
max(decode(sensor_name,'OrderNumber',string_value,null)) ONum,
max(decode(sensor_name,'RevisionNumber',string_value,null)) RNum
FROM PRD_SOAINFRA.composite_sensor_value
GROUP BY composite_instance_id) senst
WHERE bi.COMPOSITE_NAME = es.process_name
AND ad.detail_id = 0
AND bi.cpst_inst_created_time + interval '7' day > systimestamp
AND bi.cikey = ad.cikey
AND ad.DOC_REF = xd.DOCUMENT_ID(+)
and senst.composite_instance_id = bi.cmpst_id
);
Soa-infra data를 오랜 기간 동안 보관해야 한다면? soa-infra 테이블을 파티셔닝하고, 기간별로 삭제하는 것이 가장 이상적인 방법이다.
But some clients want to keep received payloads to reinitiate the faulted process to resolve unexpected system crash or make sure the guaranteed delivery between two different management team's responsibility, especially, politicians :-P. So, it is required to be desinged retention period of delivered queue or history tables.
하지만, 일부 고객들은 수신한 메시지를 보관하고 싶어 하는데 그 이유는 예기치 못했던 시스템 장애 시에 실패한 프로세스를 간단하게 재기동하거나 메시지를 올바르게 전달했다는 기록을 갖고 싶어하기 때문이다. 그래서 메시지 큐나 이력 테이블의 보관주기를 설계하고
데이타를 유지하려고 한다.
In the large SOA integrated system, it is frequently required to purge soa-infra to avoid tablespace growth. How to resolve unexpected new requirement to keep BEPL payload with limited soa-infra tablespace timely?
하지만 규모가 큰 SOA 통합 시스템에서는 DB가 비대해지는 것을 막기 위해 soa-infra에 대한 purge작업이 꼭 필요하다. 이러한 두 가지 요건을 모두 만족하면서 BPEL의 payload를 일정기간 유지할 수 있는 방법이 있을까?
My suggestion is to backup BPEL payloads from soa-infra as it is required.
Here's my design and sample backup SQL:
내가 제안하는 방법은 soa-infra 테이블에서 BPEL의 payload만을 추출하여 별도로 백업해 놓는 방법이다.
상세한 내용은 아래의 그림과 backup SQL을 참조하기 바란다.
INSERT /*+ append */ INTO exp_payload (
SELECT es.guid,
bi.ECID,
bi.CIKEY,
SensT.ONum,
Senst.rnum,
ad.bin bin,
xd.document document,
xd.DOCUMENT_TYPE document_type,
bi.cpst_inst_created_time created_time,
null updated_time,
bi.CREATION_DATE,
bi.MODIFY_DATE
FROM PRD_SOAINFRA.exp_source es,
PRD_SOAINFRA.cube_instance bi,
PRD_SOAINFRA.audit_details ad,
PRD_SOAINFRA.xml_document xd,
(SELECT composite_instance_id,
max(decode(sensor_name,'OrderNumber',string_value,null)) ONum,
max(decode(sensor_name,'RevisionNumber',string_value,null)) RNum
FROM PRD_SOAINFRA.composite_sensor_value
GROUP BY composite_instance_id) senst
WHERE bi.COMPOSITE_NAME = es.process_name
AND ad.detail_id = 0
AND bi.cpst_inst_created_time + interval '7' day > systimestamp
AND bi.cikey = ad.cikey
AND ad.DOC_REF = xd.DOCUMENT_ID(+)
and senst.composite_instance_id = bi.cmpst_id
);
덧글