Materialized View

---------------------------
-- Example Fast Refresh: --
---------------------------
conn /as sysdba@DBTEST
create public database link appo connect to usr_name identified by "abc123" using 'DBTEST';
drop user usr_name;
create user usr_name identified by abc123 default tablespace users quota unlimited on users;
grant connect, resource to usr_name;
grant create materialized view to usr_name;

conn usr_name/abc123@DBTEST4
create table appo (nome varchar2(100));
alter table appo add constraint appo_pk primary key (nome);
CREATE MATERIALIZED VIEW LOG ON appo;

conn usr_name/abc123@DBTEST
select count(*) from appo@appo;
CREATE MATERIALIZED VIEW appo_mv
BUILD IMMEDIATE
REFRESH FAST ON DEMAND --FORCE Prova prima fare la Fast, se non ce la fà, fa una Complete
AS SELECT * FROM appo@DBTEST4;
execute DBMS_REFRESH.MAKE(name => 'mv_gr1',list => 'appo_mv', next_date => sysdate+1, interval =>'sysdate+1/48');
execute DBMS_REFRESH.REFRESH( name => 'mv_gr1');
select count(*) from appo_mv;
--0

conn usr_name/abc123@DBTEST4
insert into appo values ('sdvasvasdvas');
commit;

conn usr_name/abc123@DBTEST
execute DBMS_REFRESH.REFRESH( name => 'mv_gr1');
SQL> select * from appo_mv;
NOME
-----------------
sdvasvasdvas

------------------------
-- Materialized View  --
------------------------
La Materialized View è un segmento di tipo tabella che viene refreshata periodicamente in base ad una query prestabilita che interroga un'altro schema/database. Una delle differenze fra tabella normale ed vista materializzata è l'impossibilità per quest'ultima di aggiungere o modificare le colonne.
Quando la MV viene ceata, in automatico viene associato un indice (o pk o rowid in base alla tabella source e lo script DDL di create) chiamato: _PK (pk) I_SNAP$_ (rowid).
Se si crea una M.V. con la clausola "FOR UPDATE", diviene una vista modificabile e gli verrà associate ache l'oggetto tabella USLOG$_MvName.
Se la M.V. viene creata con la clausola "FAST REFRESH", nello schema source verrà creato anche l'oggetto MLOG$_MvName.  Quest'ultime due tabelle (MLOG$_, USLOG$_) raccoglieranno i delta da applicare rispettivamente alla tabella/MV source ed al Vista Materializzata target.

Le viste Materializzate possono essere gestite tramite gruppi per facilitarne il maintenance.

----------------------
-- Data Dictionary  --
----------------------
ALL_MVIEWS                DBA_MVIEWS                   USER_MVIEWS
all_snapshots(in più della all_mviews ha le colonne CURRENT_SNAPSHOTS and SNAPSHOT_ID)

ALL_BASE_TABLE_MVIEWS     DBA_BASE_TABLE_MVIEWS        USER_BASE_TABLE_MVIEWS
-                         DBA_MVIEW_LOG_FILTER_COLS    -
ALL_MVIEW_LOGS            DBA_MVIEW_LOGS               USER_MVIEW_LOGS
ALL_MVIEW_REFRESH_TIMES   DBA_MVIEW_REFRESH_TIMES      USER_MVIEW_REFRESH_TIMES
-                         DBA_RCHILD                   -
ALL_REFRESH               DBA_REFRESH                  USER_REFRESH
ALL_REFRESH_CHILDREN      DBA_REFRESH_CHILDREN         USER_REFRESH_CHILDREN
ALL_REGISTERED_MVIEWS     DBA_REGISTERED_MVIEWS        USER_REGISTERED_MVIEWS

ALL_REPGROUP
ALL_REPSITES

set line 175 pagesize 75
alter session set nls_date_format="dd/mm yyyy hh24:mi:ss";
column OWNER format a20
column MVIEW_NAME format a30
column MASTER_LINK format a20
select OWNER,
       MVIEW_NAME,
       UPDATABLE,
       MASTER_LINK,
       REFRESH_MODE,
       REFRESH_METHOD,
       FAST_REFRESHABLE,
       LAST_REFRESH_TYPE,
       LAST_REFRESH_DATE
 from  ALL_MVIEWS
;

SET LINESIZE 175 pagesize 75
COLUMN owner         FORMAT a25
COLUMN name          FORMAT a25
COLUMN MASTER_OWNER  FORMAT a25
COLUMN MASTER        FORMAT a25
  SELECT *
    FROM DBA_MVIEW_REFRESH_TIMES
--   WHERE NAME LIKE '%MVIEW_MASTER%'
ORDER BY LAST_REFRESH;

------------
-- GRANT  --
------------

GRANT CREATE MATERIALIZED VIEW TO schema_user;

GRANT CREATE DATABASE LINK     TO schema_user; --Se serve..

----------------
-- DDL Create --
----------------
CREATE MATERIALIZED VIEW view-name
BUILD [IMMEDIATE | DEFERRED]
REFRESH [FAST | COMPLETE | FORCE ]
ON [COMMIT | DEMAND ]
[[ENABLE | DISABLE] QUERY REWRITE]
[ON PREBUILT TABLE]
AS SELECT ...;
IMMEDIATE:La vista materializzata viene popolata subito.
DEFERRED :La vista materializzata viene popolata al primo refresh.

COMPLETE :La tabella M.V. viene troncata e ripopolata con I dati estrapolati dalla query associate alla M.V.
FAST     :Necessita della M.V. Log nello schema.tabella source, essa viene usata per raccogliere i delta sulla tabella originale per poi essere applicati alla M.V.
FORCE    :Prova prima fare la Fast, se non ce la fà, fa una Complete

ON COMMIT:Il refresh avviene sul commit eseguito sulla tabella source. Non può essere usato se i database sono diversi.
ON DEMAND:Il refresh avviene su richiesta (manual o schedulata)

--------------------------------------
-- GET DDL della Materialized View  --
--------------------------------------

--> MetaScript

set line 150 pagesize 5000

select 'select DBMS_METADATA.GET_DDL(''MATERIALIZED_VIEW'','''||MVIEW_NAME||''','''||OWNER||''')||'';'' from dual;'
from dba_mviews
where OWNER not in ('APPQOSSYS', 'DIP', 'ORACLE_OCM', 'ANONYMOUS', 'EPG', 'CTXSYS', 'DBSNMP', 'EXFSYS', 'LBACSYS', 'MDSYS', 'MGMT_VIEW', 'OLAPSYS', 'OWBSYS', 'ORDPLUGINS',  'ORDSYS', 'OUTLN', 'SI_INFORMTN_SCHEMA', 'SYS', 'SYSMAN', 'SYSTEM', 'TSMSYS', 'WK_TEST', 'WKSYS', 'WKPROXY', 'WMSYS', 'XDB', 'XS$NULL', 'XS\$NULL', 'BI', 'HR', 'OE', 'PM', 'IX', 'SH', 'PUBLIC')
  order by 1, OWNER, MVIEW_NAME
  ;

--> Script

set long 40000 longchunksize 40000 line 250 pagesize 0select DBMS_METADATA.GET_DDL('MATERIALIZED_VIEW','MV_Name','Schema')||';' from dual;

--------------

-- Snapshot --
--------------
set line 175 pagesize 75
column mview format a35
column tabella format a35
column mmview format a35
column REFRESH_MET format a35
column MASTER_LINK format a15
column ERROR format 99999
select OWNER||'.'||NAME mview,
       TABLE_NAME tabella,
       --MASTER_VIEW||'.'||MASTER_OWNER mmview,
       MASTER,
       MASTER_LINK,
       REFRESH_METHOD,
       LAST_REFRESH,
       ERROR
--       ,REFRESH_GROUP
from all_snapshots
where REFRESH_GROUP=61
;

-----------------------------
-- Materialized View Index --
-----------------------------

-->Gli indici vengono create in automatic se si crea una M.V. con Fast Refresh

set line 150 pagesize 75
column OWNER format a20
column INDEX_NAME format a30
column INDEX_TYPE format a25
column TABLE_NAME format a30
column TABLE_OWNER format a20
select
       OWNER      ,
       INDEX_NAME ,
       INDEX_TYPE ,
       UNIQUENESS ,
       TABLE_OWNER,
       TABLE_NAME ,
       TABLE_TYPE
from all_indexes
where OWNER='XBSESDBO'
  and table_name='NOME_MV'                     --NomeVistaMaterializzata
  and INDEX_NAME like '%\_PK%'     escape '\'  -- Indice su Primary Key
   or index_name like '%I\_SNAP$%' escape '\'  -- Indice su ROWID
;

-------------------
-- ON COMMIT     --
-------------------
-->Con questa clausola la vista materializzata viene refreshiata sul commit effettuato data tabella/MV source.

NOTE: Non si può usare su database remoti
ATTENZIONE: Non si deve refreshare manualmente.. sennò è necessario il suo rebuild.

-------------------
-- FOR UPDATE    --
-------------------
La Vista Materializzata può essere creata con la clausola FOR UPDATE. In questo caso verrà creata una tabella di appoggio che riporterà i delta applicati alla vista con la seguente nomenclatura: USLOG$_nome_vistamaterializzata.

create materialized view nome_vistamaterializzata
for update
as select * from nome_tabellasource@SERVICE01
;

--> STEP  standard di un Refresh per una M.V. con la clausola "For Update":

           - Prima trasferisce i delta dalla Slave/Target/M.V.Site al Source/MasterSite.

           - Poi I dati della MasterSite/Source sono applicati sulla Slave/Target/M.V.Site.

-------------------
-- QUERY REWRITE --
-------------------
-La clausola QUERY REWRITE permette all'optimizer di usare la Materialized View per query che non la chiamano direttamente ma richiamano i dati della tabella sottostante.

CREATE MATERIALIZED VIEW cal_month_sales_mv
ENABLE QUERY REWRITE AS
SELECT  t.calendar_month_desc, SUM(s.amount_sold) AS dollars
FROM sales s, times t WHERE s.time_id = t.time_id
GROUP BY t.calendar_month_desc;

-->EXPLAIN PLAN

EXPLAIN PLAN FOR
SELECT  t.calendar_month_desc, SUM(s.amount_sold)
FROM  sales s, times t WHERE s.time_id = t.time_id
GROUP BY t.calendar_month_desc;

OPERATION                  OBJECT_NAME
--------------------       -----------
SELECT STATEMENT
MAT_VIEW REWRITE ACCESS    CALENDAR_MONTH_SALES_MV

-----------------------
-- ON PREBUILT TABLE --
-----------------------
--> Può essere usata dopo che si è già create una tabella identica all'originle con un "create table xxx as select * from xxx" (CTAS). Con questa clausola "ON PREBUILT TABLE" la Vista Materializzata non crea un nuovo oggetto (segmento tabella) ma costruisce solo la DDL su un oggetto/tabella preesistente. Al refresh della vista materializzata verrà refreshata la tabella pre-costruita. Ovviamente la tabella deve soddistare I requiiti (deve avere le stesse colonne) della query sottostante la creazione della M.V. Di solito si usa in associazione alla clausola  “create table as select”.

-->Esempio Clausola "PREBUILT TABLE"
create table mv1 as select * from TAB_TEST@localservicename;
CREATE MATERIALIZED VIEW mv1
ON PREBUILT TABLE
REFRESH FORCE ON DEMAND
AS select * from TAB_TEST@localservicename;

--------------------------------------

--  Materialized View FAST REFRESH  --
--------------------------------------

ATTENZIONE: 

- Una Vista Materializzata non può essere con refresh fast se è di tipo complesso:
           --> A CONNECT BY claue.
           --> INTERSECT, MINUS, or UNION ALL set operation.
           --> DISTINCT or UNIQUE keyword.
           --> In alcuni casi aggregate function.
           --> In alcuni casi joins other nelle subquery.
           --> In alcuni casi UNION operation.

PUNTI DI FORZA:

 La fast Refres supporta l'uso del SQL*Loader o le altre "bulk load" utility per l'inserimento dei dati nella tabella/MV Source del MasterSite.

 In questi casi Oracle crea un log del direct loader (da usare poi nel fast refresh) quando viene eseguito un direct-path INSERT sulla tabella Source/MasterSite.

--> Tabella dei LOG

Prima di creare la Materialized View Fast Refresh, bisogna prima creare una tabella sull'ambiente MasterSite che raccolga i delta dei cambiamenti avvenuta sulla tabella/MV Source. La "Materialized View Logs" (owner.MLOG$_nome_tabella) cattura il delta che viene apportato alla tabella source (owner.nome_tabella) per poi venire applicato (ON COMMIT, ON DEMAND) sulla vista materializzata collegata: al refresh la MV viene scritta in base ai dati della "Materialized View Table Logs" e successivamente quest'ultima viene resettata/azzerata.

CREATE MATERIALIZED VIEW LOG ON [schema.]table_name
[... storage options ...]
[... table_partitioning_clause ...]
[WITH {OBJECT | PRIMARY KEY | ROWID | SEQUENCE | column_list}]
[{INCLUDING | EXCLUDING} NEW VALUES];

--> Esempio:

CREATE MATERIALIZED VIEW LOG

ON schema_owner.TAB_TEST
TABLESPACE tools
WITH ROWID -- WITH PRIMARY KEY
INCLUDING NEW VALUES --EXCLUDING NEW VALUES

;
Opzione "INCLUDING/EXCLUDING NEW VALUES":

Specificando INCLUDING:             Salva i new e gli old. Si usa sulle single Master Table su cui viene costruita una Vista Materializzata Aggregata (su più tabelle) Fast.

Specificando EXCLUDING (new): Salva gli old. E' per default. si usa per evitare un overhead di informazioni. NON usare per M.V. FAST Aggregate.

-->Data Dictionary Elenco delle tabelle dei log.
set line 120
select LOG_OWNER,
       MASTER,
       LOG_TABLE,
       PRIMARY_KEY
from ALL_MVIEW_LOGS
;-->Tabella dei delta sul MasterSite
select * from MLOG$_nome_tabella;

-->Esempio SCRIPT CREAZIONE Materialized View FAST REFRESH (Schema DB Slave Site)
CREATE MATERIALIZED VIEW mv1
BUILD IMMEDIATE
REFRESH FORCE ON DEMAND  --FORCE Prova prima fare la Fast, se non ce la fà, fa una Complete
AS SELECT * FROM  TAB_TEST@localnetworkservice

;

-->  Purging Rows from a Materialized View Log (FAST REFRESH) --BEGIN
   DBMS_MVIEW.PURGE_LOG (
      master => 'owner_schema.nome_tabella',
      num    => 1,
      flag   => 'DELETE');
END;
/

num --> Number of least recently refreshed materialized views whose rows you want to remove from materialized view log.To delete all rows in the materialized view log, indicate a high number of materialized views to disregard, as in this example: DBMS_MVIEW.PURGE_LOG('master_table',9999);
flag--> Per default il suo valore lascia la precedenza al parametro precedente, se invece viene settato a 'DELETE' allora sovrascrive il parametro precedente e cancella tutti i log.

-------------
-- Esempio --
-------------
CREATE DATABASE LINK DB1.WORLD CONNECT TO schema_user IDENTIFIED BY xxxx USING 'DB1.WORLD';
CREATE MATERIALIZED VIEW emp_mv
BUILD IMMEDIATE
REFRESH FORCE ON DEMAND   --FORCE Prova prima fare la Fast, se non ce la fà, fa una Complete
AS SELECT * FROM emp@db1.world;

-->Ricordarsi di far girare le statistiche dopo la creazione della Materialized View.

BEGIN
  DBMS_STATS.gather_table_stats(
    ownname => 'schema_name',
    tabname => 'nome_mv_tab');
END;
/
-------------
-- Refresh --
-------------
- F :Fast Refresh,         -->Refresha solo I delta dell'oggetto tabella/MV source
- ? :Force Refresh,      -->Se possibile esegue FAST refresh ; altrimenti esegue il COMPLETE refresh
- C :Complete Refresh -->Ricrea tutti I record della source nella MV

- A :Always Refresh     -->Equivalente alla C.

--> DBMS_MVIEW.Refresh

Questo pacchetto (fra le tante cose che può fare) è capace di aggiornare le viste materializzate (che non fanno parte dello stesso refresh group).

DBMS_MVIEW.REFRESH (
   { list                 IN     VARCHAR2,
   | tab                  IN     DBMS_UTILITY.UNCL_ARRAY,}
   method                 IN     VARCHAR2       := NULL,
   rollback_seg           IN     VARCHAR2       := NULL,
   push_deferred_rpc      IN     BOOLEAN        := true,
   refresh_after_errors   IN     BOOLEAN        := false,
   purge_option           IN     BINARY_INTEGER := 1,
   parallelism            IN     BINARY_INTEGER := 0,
   heap_size              IN     BINARY_INTEGER := 0,
   atomic_refresh         IN     BOOLEAN        := true,
   nested                 IN     BOOLEAN        := false);

--> Refresh ALL M.V.

set pagesize 500
select 'exec DBMS_MVIEW.REFRESH('''||OWNER||'.'||MVIEW_NAME||''');'
from all_mviews
where OWNER in ('PBS01','PRB01')
order by OWNER, MVIEW_NAME
;

--> Refresh 1 M.V.

exec DBMS_MVIEW.REFRESH('OWNER.MVIEW_NAME','C');

Note: "C" sta per Complete

--> V$MVREFRESH per verificare quele MV si sta refreshando correntemente:

COLUMN CURRMVOWNER HEADING 'Owner' FORMAT A15
COLUMN CURRMVNAME HEADING 'Materialized|View' FORMAT A25
SELECT CURRMVOWNER, CURRMVNAME

FROM V$MVREFRESH

;

-->Schedulazione Refresh:

CREATE MATERIALIZED VIEW nome_mv
REFRESH FAST
START WITH SYSDATE NEXT SYSDATE+20/(24*60)
FOR UPDATE
AS SELECT * FROM ABC WHERE TMSTP> SYSDATE-1;
 

Esempio
WHERE (date) > sysdate - 7/24;	7 ore
WHERE (date) > sysdate - 7;	7 giorni
WHERE (date) > sysdate - 7/1440;	7 minuti
7/24 13/24	7 ore 13 ore
1/24/60/60 7/24/60/60	1 sendo 7 secondi
1/24/60 5/24/60	1 minuto 5 minuti
1/24 5/24	1 ora 5 ore
TRUNC(SYSDATE+1/24,'HH')	ogni ora a aprtire dalla prossima ora

--> Schedulazione: Analisi del Job associate (vedere anche trace SID_jxx0_yyyyy.trc)
set line 175 pagesize 75
column job format 99999
column WHAT format a55
select    job,
          what,
          THIS_DATE,
          LAST_DATE,
          NEXT_DATE,
          TOTAL_TIME,
          broken,
          failures
from dba_jobs
where job=81
order by last_date
;

--> Execute Job Legato ad un Refresf Schedulato

execute dbms_job.run(81);

-----------------------------
-- Materialized View Group --
-----------------------------

Il pacchetto DBMS_REFRESH.MAKE serve per creare un gruppo di vise materializzate da refreshare tutte assieme:

--> Esempio 1:

execute DBMS_REFRESH.MAKE(name => 'mv_group_1',list => ' mview_1, mview_2', next_date => sysdate+1, interval =>'sysdate+1/48'); 

--> Esempio 2

BEGIN
   DBMS_REFRESH.make(
     name                 => 'SCOTT.MINUTE_REFRESH',
     list                 => '',
     next_date            => SYSDATE,
     interval             => '/*1:Mins*/ SYSDATE + 1/(60*24)',
     implicit_destroy     => FALSE,
     lax                  => FALSE,
     job                  => 0,
     rollback_seg         => NULL,
     push_deferred_rpc    => TRUE,
     refresh_after_errors => TRUE,
     purge_option         => NULL,
     parallelism          => NULL,
     heap_size            => NULL);
END;
/

NOTE PER DBMS_REFRESH.MAKE:
push_deferred_rpc    -->Si usa solo per le MV updatabili. Bisogna usare il valore di default "true" se si vuole applicare I cambiamenti dalla MV alla Master (table/MV) prima del refresh della MV stessa. Diversamente, con "false", se si refreshia la vista i dati modificati della stessa andranno persi.
refresh_after_errors -->Si usa solo per le MV updatabili. E' legato al parametro recedente: in base al risultato del push_deferred_rpc (corretto o in errore), si stabilise se proseguire nel refresh della vista o meno.

--> Refresh MV Group <--
Durante il Refresh ogni MV del grupo è lockata per il tempo del refresh totale.

--> Pacchetto: DBMS_MVIEW.REFRESH.
exec DBMS_MVIEW.REFRESH (list => 'FAGGA_PR', method => 'C' );
exec DBMS_REFRESH.REFRESH('gropu_name');

Per vedere la data di Refresh si dovrà interrogare la vista DBA_MVIEW_REFRESH_TIMES:
SET LINESIZE         175
SET PAGESIZE         500
COLUMN owner         FORMAT a25
COLUMN name          FORMAT a25
COLUMN MASTER_OWNER  FORMAT a25
COLUMN MASTER        FORMAT a25
  SELECT *
    FROM DBA_MVIEW_REFRESH_TIMES
--   WHERE NAME LIKE '%MVIEW_MASTER%'
ORDER BY LAST_REFRESH;

--> ALTRI PACCHETTI DBMS_REFRESH  <--

CHANGE   (Cambia l'intervallo dii tempo del refresh)
DESTROY  (Rimuove le MV dal gruppo e cancella il gruppo stesso)
SUBTRACT (Rimuove le MV dal gruppo)
ADD      (Aggiunge MV al gruppo)

Si può usare il pacchetto DBMS_REFRESH.ADD per aggiungere una vista materializzata al gruppo creato precedentemente:

execute DBMS_REFRESH.ADD( name => 'my_group_1', list => 'mv_borrowing_rate');

Il pacchetto BMS_REFRESH.SUBTRACT elimina le viste materializzate da un gruppo creato precedentemente.
execute DBMS_REFRESH.SUBTRACT( name => 'my_group_1', list => 'mv_market_rate');

Il pacchetto DBMS_REFRESH.REFRESH è per comandare il refresh di tutto il gruppo
execute DBMS_REFRESH.REFRESH( name => 'my_group_1');

Per modificare l'intervallo di refresh usare il pacchetto DBMS_REFRESH.CHANGE
execute DBMS_REFRESH.CHANGE( name => 'my_group_1', next_date => NULL, interval => 'sysdate+1/96');

Per rimuovere il tutto usare DBMS_REFRESH.DESTROY (cancella materialized views ed il refresh group):
execute DBMS_REFRESH.DESTROY( name => 'my_group_1');

--> DATA DICTIONARY GROUP <-- 

La tabella ALL_REFRESH riporta tutti i Groups di MV:
column ROWNER format a20
column RNAME format a25
column INTERVAL format a35

set line 175 pagesize 75
select ROWNER,
       RNAME,
       REFGROUP,
       JOB,
       NEXT_DATE,
       INTERVAL,
       BROKEN,      -->Y significa che il job è ko e non girerà più
       PARALLELISM,
       PUSH_DEFERRED_RPC,   -->(Create MV FOR UPDATE) Indica se i cambiamenti sono applicati dalla vista
                            --  materializzata alla tabella/vista master prima del refrs (Y) o dopo (N)
       REFRESH_AFTER_ERRORS --> Indica se si procede con il refresh nonostante un errore sul pushing deferred RPCs (vedi campo precedente)
from all_refresh--where BROKEN='N'
;

ALL_REFRESH_CHILDREN  riporta la Lista delle MV nel Gruppo (anche Job Associato alla Schedulazione del Refresh)
set line 175 pagesize 75
column mv format a40
column TYPE format a25
column ROWNER format a12
column RNAME format a22
column refg  format 9999
column JOB   format 9999
column PURGE format 99999
column PARAL format 99999
column INTERVAL format a20
select OWNER||'.'||NAME mv,
--       TYPE                ,
       ROWNER              ,
       RNAME               ,
       REFGROUP            refg,
       IMPLICIT_DESTROY    ,
       PUSH_DEFERRED_RPC   ,
       REFRESH_AFTER_ERRORS,
       JOB                 ,
       NEXT_DATE           ,
       INTERVAL            ,
       BROKEN              ,
       PURGE_OPTION        purge,
       PARALLELISM         paral
from ALL_REFRESH_CHILDREN 
;

ROWNER                Name owner of Refresh Group
RNAME                 Name Refresh groupREFGROUP              Internal identifier Refresh Group
IMPLICIT_DESTROY      (Y| N) If Y, then destroy the refresh group when its last item is subtracted
PUSH_DEFERRED_RPC     (Y |N) If Y then push changes from snapshot to master before refreshREFRESH_AFTER_ERRORS  If Y, proceed with refresh despite error when pushing deferred RPCs
ROLLBACK_SEG          Name of the rollback segment to use while refreshingNEXT_DATE             Date that this job will next be refreshed automatically, if not broken
INTERVAL              A date function used to compute the next NEXT_DATEBROKEN                (Y |N) Y means the job is broken and will never be run
PURGE_OPTION          The method for purging the transaction queue after each push. 1 indicates quick purge option; 2 indicates precise purge optionPARALLELISM           The level of parallelism for transaction propagation
HEAP_SIZE             The size of the heap

--> DBA_RCHILD lista tutti i igli in ogni Group di MV.
set line 175 pagesize 75
column mv format a40
select OWNER||'.'||NAME    mv,
       REFGROUP,
       TYPE#
from DBA_RCHILD
;
REFGROUP  Internal identifier of refresh group
OWNER Owner of the object in the refresh group
NAME Name of the object in the refresh group
TYPE#  Type of the object in the refresh group

ALL_REPGROUP
ALL_REPSITES

--> Refrsh Automatico a seguito di un errore:
Quando Oracle fallisce un refresh Group (Job Oracle), riprova automaticamente a refreshare dopo 1 minuto, poi due minuti, 4 minuti e cosi via..fino a 16 volte, dopodichè mette il gruppo in Broken (colonna BROKEN in USER_REFRESH e USER_REFRESH_CHILDREN della data dictionary). L'errore è riportato nei file di trace nella "diagnostic dest" ed è legato al JOB associato. Dopo aver corretto il problema bisogna far ripartire il gruppo manualemnte ed oracle azzera il broken ripropoenendo il refresh automatico.

--> Job a seguito di Schedulazioni

Per un controllo più approfondito (nel caso di schedulazioni), andare anche a vedere la DBA_JOBS_RUNNING (e se ci sono problem il parametro di inizzializzazione JOB_QUEUE_PROCESSES).

set line 175 pagesize 75
column job format 99999
column WHAT format a55
select    job,
          what,
          THIS_DATE,
          LAST_DATE,
          NEXT_DATE,
          TOTAL_TIME,
          broken,
          failures
from dba_jobs
where job=81  --Vedere il valore nella all_refresh.job

order by last_date
;

--> Execute Job Legato ad un Refresf Schedulato

execute dbms_job.run(81);

-----------------------------------
-- Multitier Materialized Views  --
-----------------------------------
Multitier Materialized Views è una Materialized Views create su un altra Materialized Views. Può essere read-only o updatable. Materialized View costruita su tabella o altra MV è chiamata di "level 1", altra Materialized Views costruita su una tabella/MV di "level 1" è chiamata "level 2" (e così via).

Ogni Master Materialized View può avere molte Materialized View basate su di essa..


-----------------------------------------------
-- M.V Registration (lato Source/MasterSite) --
-----------------------------------------------
Tramite questa vista si possono anche vedere facilmente quali sono le tabelle che hanno delle viste materializzate associate.

--> Viste Registrate:
set line 175 pagesize 75
column mv format a35
column MVIEW_SITE format a35
select OWNER||'.'||NAME mv,
       MVIEW_SITE,
       CAN_USE_LOG,
       REFRESH_METHOD
from ALL_REGISTERED_MVIEWS
;

Oracle non garantisce la Registration/Unregistration delle MV sul loro master site durante la creazione/drop della MV. In alternative si può completare la registration/unregistration manualmente tramite il pacchetto DBMS_MVIEW.REGISTER_MVIEW.