Создание материализованного представления Oracle занимает 6 минут, но обновление занимает 42 минуты, почему?

Question

Заранее спасибо, если вы можете решить эту проблему.

Я работаю на базе 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; 

Answer 1

попробовать делать:

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

Атомный обновление ложных означает, что он будет укоротить затем вставить. Если вы используете атомное обновление, он сделает транзакционную delete + insert (по умолчанию я считаю). «Безопаснее», но может быть намного дольше.

Конечно, он не гарантирует, что всегда требуется то же самое время, чтобы завершить обновление. Например, если у вас одновременно есть много других процессов (конкурирующих за ресурсы), вы можете столкнуться с «медленностью» по сравнению с другими режимами работы.

Кроме того, если кто-то другой получает доступ к этой таблице моментальных снимков в транзакции с длительным сроком действия, вы можете быть заблокированы на некоторое время, пытаясь выполнить полное обновление (используя atomic_refresh => false). Поэтому, возможно, проверьте блокировку блокировок, если это займет некоторое время.