오라클 구체화보기 생성에는 6 분이 소요되지만 새로 고침에는 42 분이 걸리는 이유는 무엇입니까?

이 문제를 해결할 수 있다면 미리 감사드립니다.오라클 구체화보기 생성에는 6 분이 소요되지만 새로 고침에는 42 분이 걸리는 이유는 무엇입니까?

저는 Oracle 11g r2 데이터베이스에서 실행 중이며 새로운 구체화 된보기를 작성하고 있습니다.보기 작성에는 약 6 분이 걸리지 만, 새로 고치기 위해 매일 약 42 시간이 소요됩니다. 의사록. 이 코드를 새로 고치려면 REFRESH_ACTIVE_NON_ACQU_MV 프로 시저가 아래에 있으며 구체화 된보기를 만드는 코드는 맨 아래에 있습니다. 내가 뭘 잘못하고 있니?

난 그냥 25 분 정도 걸립니다 아래 코드를 사용하여 간단한 새로 고침을

begin 
    EXECUTE IMMEDIATE 'ALTER SESSION ENABLE PARALLEL DML'; 
    dbms_mview.REFRESH('ACTIVE_NON_ACQU_MV'); 
end; 
/

그러나 아래 절차는 42 분이 걸립니다. 내가 왜 구체화 된 뷰를 만드는 것보다 새로 고치는 것이 더 오래 걸리는지 이해하지 못합니다 ?? 두 가지 새로 고침이 새로 고침하는 데 소요되는 시간면에서 왜 그렇게 넓습니까?

PROCEDURE REFRESH_ACTIVE_NON_ACQU_MV 
IS 
    l_method VARCHAR2(1) := 'C'; 
BEGIN 
    EXECUTE IMMEDIATE 'ALTER SESSION ENABLE PARALLEL DML'; 
    Dbms_Mview.Refresh(LIST=>'ACTIVE_NON_ACQU_MV', 
    METHOD=>l_method, atomic_refresh=>FALSE, PARALLELISM=>8); 

END REFRESH_ACTIVE_NON_ACQU_MV;

아래의 구체화 된보기를 생성하는 코드. 일을

PROMPT Drop MATERIALIZED VIEW ACTIVE_NON_ACQU_MV 
-- create create MATERIALIZED VIEW ACTIVE_NON_ACQU_MV 
DROP MATERIALIZED VIEW ACTIVE_NON_ACQU_MV; 
-- create create MATERIALIZED VIEW ACTIVE_NON_ACQU_MV 
PROMPT Create MATERIALIZED VIEW ACTIVE_NON_ACQU_MV 
CREATE MATERIALIZED VIEW ACTIVE_NON_ACQU_MV (SUPPLIER, 
              BROADCASTER, 
              PRODUCTION_TITLE, 
              PRODUCTION_NUMBER, 
              SERIES_TITLE, 
              SUPPLIED_SOURCE_IND, 
              THIRD_PARTY_GROUP_ID, 
              BRO_BROADCAST_BY_TP_SURR_ID, 
              STATION_ID           
              )           
TABLESPACE PRBLK_MV_BD_A 
PCTUSED 0 
PCTFREE 10 
INITRANS 2 
MAXTRANS 255 
STORAGE (
      INITIAL   64K 
      NEXT    1M 
      MAXSIZE   UNLIMITED 
      MINEXTENTS  1 
      MAXEXTENTS  UNLIMITED 
      PCTINCREASE  0 
      BUFFER_POOL  DEFAULT 
      ) 
NOCACHE 
LOGGING 
NOCOMPRESS 
PARALLEL (DEGREE DEFAULT INSTANCES DEFAULT) 
BUILD IMMEDIATE 
USING INDEX 
      TABLESPACE PRBLK_MV_BI_A 
      PCTFREE 10 
      INITRANS 2 
      MAXTRANS 255 
      STORAGE (
         INITIAL   64K 
         NEXT    1M 
         MINEXTENTS  1 
         MAXEXTENTS  UNLIMITED 
         PCTINCREASE  0 
         BUFFER_POOL  DEFAULT 
         ) 
REFRESH ON DEMAND 
WITH ROWID 
AS 
/* Formatted on Mon/06/02/2017 10:07:52 (QP5 v5.267.14150.38573) */ 
select x.supplier_name as supplier , 
     x.broadcaster_name as broadcaster , 
     ptle.title as production_title , 
     x.production_number as production_number , 
     stle.title as series_title , 
     x.production_source as supplied_source_ind , 
     x.third_party_group_id , 
     x.bro_broadcast_by_tp_surr_id, 
     x.STATION_ID 
FROM 
(select usages.production_number, 
     usages.prod_exploitation_cre_surr_id, 
     usages.bro_broadcast_by_tp_surr_id, 
     usages.THIRD_PARTY_SURR_ID, 
     usages.SUPPLIER_NAME, 
     usages.THIRD_PARTY_GROUP_ID, 
     usages.STATION_ID, 
     usages.BROADCASTER_NAME, 
     prod.cre_surr_id, 
     prod.production_source, 
     prod.prod_series_cre_surr_id 
from productions prod, 
(SELECT --+ parallel(uh) 
     uh.production_number, 
     uh.prod_exploitation_cre_surr_id, 
     uh.bro_broadcast_by_tp_surr_id, 
     supplier_details.THIRD_PARTY_SURR_ID, 
     supplier_details.SUPPLIER_NAME, 
     supplier_details.THIRD_PARTY_GROUP_ID, 
     supplier_details.STATION_ID, 
     supplier_details.BROADCASTER_NAME, 
     row_number() over(partition by uh.production_number order by uh.production_number) prod_rows 
FROM usage_headers uh, 
     (SELECT third_party.surr_id AS THIRD_PARTY_SURR_ID, 
       third_party.supplier_name as SUPPLIER_NAME, 
       third_party.supplier_group_id AS THIRD_PARTY_GROUP_ID, 
       third_party.dn_root_tp_surr_id AS THIRD_PARTY_ROOT_ID, 
       bro.station_id AS STATION_ID, 
       bro.dn_tp_name AS BROADCASTER_NAME 
     FROM broadcasters bro, 
        (SELECT tp.surr_id, 
          tp.name AS supplier_name, 
          tp.tp_surr_id AS supplier_group_id, 
          tp.dn_root_tp_surr_id 
        FROM third_parties tp 
        CONNECT BY PRIOR tp.surr_id = tp.tp_surr_id 
        START WITH tp.surr_id IN (SELECT surr_id FROM ETL_ACQUIRED_MASTER WHERE NVL(exclude_flag,'N') <> 'Y')) third_party 
     WHERE third_party.surr_id = bro.tp_surr_id) supplier_details 
WHERE uh.bro_broadcast_by_tp_surr_id = supplier_details.THIRD_PARTY_SURR_ID 
AND uh.production_number IS NOT NULL 
AND uh.prod_exploitation_cre_surr_id IS NOT NULL 
AND uh.right_type IN ('M', 'B') 
AND NVL (uh.dn_uls_usage_status, '3') NOT IN ('9', '11') 
AND uh.udg_surr_id IS NOT NULL 
AND NOT EXISTS (SELECT 1 
       FROM prblk.production_usage_components puc 
       WHERE puc.uh_surr_id = uh.surr_id 
       AND PUC.DISTRIBUTION_STATUS IS NOT NULL)) usages 
WHERE usages.prod_rows = 1 
AND usages.prod_exploitation_cre_surr_id = prod.cre_surr_id 
AND prod.production_source <> 'AP') x 
LEFT OUTER JOIN titles ptle ON (ptle.cre_surr_id = x.cre_surr_id AND ptle.tt_code = 'R') 
LEFT OUTER JOIN titles stle ON (stle.cre_surr_id = x.prod_series_cre_surr_id AND stle.tt_code = 'R'); 

COMMENT ON MATERIALIZED VIEW ACTIVE_NON_ACQU_MV IS 'snapshot of none acquired productions - ACTIVE_NON_ACQU_MV'; 

PROMPT select on 'ACTIVE_NON_ACQU_MV' to APPS_ACCESS_ROLE_BLK 
GRANT SELECT ON ACTIVE_NON_ACQU_MV TO APPS_ACCESS_ROLE_BLK;

출처

2017-02-07 Shaun Kinnair

시도는 :

는

exec dbms_mview.refresh('ACTIVE_NON_ACQU_MV', 'C', atomic_refresh=>false);

거짓의 원자 새로 고침은 삽입 후 잘라 의미합니다. 원자 새로 고침을 사용하는 경우 트랜잭션 삭제 + 삽입을 수행합니다 (기본값은 내가 믿는 것입니다). "안전"하지만 완료하는 데 훨씬 오래 걸릴 수 있습니다.

은 물론, 자사는 항상 새로 고침을 완료하기 위해 같은 시간을 보장 할 수 없습니다. 예를 들어 다른 프로세스가 동시에 실행되는 경우 (리소스와 경쟁하는 경우) 다른 런타임에 비해 느려질 수 있습니다. 다른 사람이 장기 실행 트랜잭션에 해당 스냅 샷 테이블에 액세스하는 경우

또한, 당신이 완전 새로 고침을하려고 잠시 동안 차단 될 수 있습니다 (거짓> atomic_refresh = 사용). 따라서 잠시 동안 잠금 장치가 잠겨 있는지 확인하십시오. dbms_mview.refresh에게 일을하려고 @tbone

출처

2017-02-07 19:23:10 tbone

안녕하세요 ('ACTIVE_NON_ACQU_MV', 'C'를 atomic_refresh => false)를; 하지만 내 절차는 이미 이렇게하고있다. –

오라클 구체화보기 생성에는 6 분이 소요되지만 새로 고침에는 42 분이 걸리는 이유는 무엇입니까?

답변

관련 문제