Refazer limite para atualização completa da visualização materializada ou equivalente manual

Um log de visualização materializada ^(MV) pode ser usado para permitir que uma MV faça uma atualização rápida que modifica apenas os dados que foram alterados. No entanto, várias condições impedem que o MV use o log e, portanto, requerem uma atualização completa. A Oracle implementou uma atualização completa atômica como uma exclusão e inserção de cada registro. Isso é feito mesmo que não haja alterações nos dados.

Existe uma maneira de tornar essa replicação inteligente em relação à refazer geração ? Um MERGE seguido por um DELETE requer consultar a fonte duas vezes. Valeria a pena coletar os dados em massa para fazer uma BULK MERGE e DELETE? Existe uma maneira melhor?

Atualizar:

Eu explorei usando uma tabela temporária global como uma área de preparação. Embora eles usem menos da metade do refazer, eles ainda usam muito.

Pretende-se apenas demonstrar o uso refazer de várias insertoperações, em vez de responder a toda a pergunta. Os resultados na minha instância de 10g não são 100% determinísticos, mas o quadro geral permaneceu o mesmo toda vez que eu corria.

Para as tabelas de heap, não sei por que o insert /*+ append */gerado refaz mais.

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);

teste:

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';

resultado:

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                   

Boa pergunta. Eu "resolvi" esse problema para a minha situação há algum tempo, fazendo os MVs e quaisquer índices neles NOLOGGING. Não havia sentido em minha situação - de qualquer maneira, eu estava atualizando completamente a exibição, por que precisaria refazer?