redo limite per vista materializzata aggiornamento completo o equivalente manuali

Question

Una vista materializzata ^(MV) registro può essere utilizzato per consentire a un MV di fare un aggiornamento rapido che modifica solo i dati che sono stati modificati. Tuttavia, varie condizioni impediscono la MV di utilizzare il registro e quindi necessitano di un aggiornamento completo. Oracle ha implementato un aggiornamento completo atomica come un'operazione di eliminazione e inserimento di ogni record. Lo fa anche se non ci sono in ultima analisi, nessuna modifica ai dati.

C'è un modo per rendere questa replica intelligente per quanto riguarda rifare generazione ? Un MERGE seguita da una DELETE richiede interrogando la sorgente due volte. Sarebbe la pena di massa raccogliere i dati per fare una fusione di massa e DELETE? C'è un modo migliore?

Aggiornamento:

Ho esplorato utilizzando una tabella temporanea globale come area di sosta. Anche se usano meno della metà del redo, che ancora usano per molto.

Answer 1

Questa è solo scopo di dimostrare l'utilizzo redo di varie operazioni insert piuttosto che la risposta tutta la questione. Risultati sul mio esempio 10g non sono al 100% deterministico, ma il quadro generale è rimasto lo stesso ogni volta che mi sono imbattuto attraverso.

Per le tabelle heap, non so il motivo per cui il insert /*+ append */ generato più redo.

Testbed:

create table heap_noappend(id integer, dummy char(500));
create table heap_append(id integer, dummy char(500));
create global temporary table gtt_noappend(id integer, dummy char(500));
create global temporary table gtt_append(id integer, dummy char(500));
create global temporary table gtt_results(stage integer, val integer);

Test:

insert into gtt_results(stage, val)
select 0, value from v$statname join v$sesstat using(statistic#)
where sid=sys_context('userenv','sid') and name='redo size';

insert into heap_noappend(id, dummy)
select level, 'A' from dual connect by level<1000;

insert into gtt_results(stage, val)
select 1, value from v$statname join v$sesstat using(statistic#)
where sid=sys_context('userenv','sid') and name='redo size';

insert /*+ append */ into heap_append(id, dummy)
select level, 'A' from dual connect by level<1000;

insert into gtt_results(stage, val)
select 2, value from v$statname join v$sesstat using(statistic#)
where sid=sys_context('userenv','sid') and name='redo size';

insert into gtt_noappend(id, dummy)
select level, 'A' from dual connect by level<1000;

insert into gtt_results(stage, val)
select 3, value from v$statname join v$sesstat using(statistic#)
where sid=sys_context('userenv','sid') and name='redo size';

insert /*+ append */ into gtt_append(id, dummy)
select level, 'A' from dual connect by level<1000;

insert into gtt_results(stage, val)
select 4, value from v$statname join v$sesstat using(statistic#)
where sid=sys_context('userenv','sid') and name='redo size';

Risultati:

select * 
from( select decode(stage,1,'heap noappend',
                          2,'heap append',
                          3,'gtt noappend',
                          4,'gtt append') as operation, 
             val-lag(val) over(order by stage) as redo 
      from gtt_results)
where redo is not null;

OPERATION     REDO                   
------------- ---------------------- 
heap noappend 606932                 
heap append   690768                 
gtt noappend  41488                  
gtt append    256                   

Answer 2

Buona domanda. I "risolto" il problema per la mia situazione un po 'indietro, rendendo la MV e di tutti gli indici su di loro NOLOGGING. Non c'era motivo ad esso la mia situazione -? Stavo facendo un aggiornamento completo della vista in ogni caso, il motivo per cui avrei bisogno rifare