Límite de rehacer para la vista materializada, actualización completa o equivalente manual

Se puede usar un registro de vista materializada ^(MV) para permitir que un MV realice una actualización rápida que solo modifica los datos que han cambiado. Sin embargo, varias condiciones impiden que el MV use el registro y, por lo tanto, requieren una actualización completa. Oracle implementó una actualización completa atómica como una eliminación e inserción de cada registro. Lo hace incluso si finalmente no hay cambios en los datos.

¿Hay alguna manera de hacer que esta replicación sea inteligente con respecto a la generación de rehacer ? Un MERGE seguido de DELETE requiere consultar la fuente dos veces. ¿Valdría la pena recopilar datos de forma masiva para hacer una BULK MERGE y DELETE? ¿Hay una mejor manera?

Actualizar:

Exploré el uso de una tabla temporal global como área de preparación. Aunque usan menos de la mitad del rehacer, todavía usan demasiado.

Esto solo pretende demostrar el uso de rehacer varias insertoperaciones en lugar de responder a la pregunta completa. Los resultados en mi instancia de 10g no son 100% deterministas, pero el panorama general se mantuvo igual cada vez que lo encontré.

Para las tablas de montón, no sé por qué insert /*+ append */generaron más rehacer.

banco de pruebas:

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

prueba:

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                   

Buena pregunta. "Resolví" este problema para mi situación hace un tiempo haciendo que los MV's y cualquier índice sobre ellos NOLOGGARA. No tenía sentido mi situación: estaba haciendo una actualización completa de la vista de todos modos, ¿por qué necesitaría rehacer?