Лимитный повтор для материализованного представления, полное обновление или ручной эквивалент

Журнал с материализованным представлением ^(MV) может использоваться для того, чтобы позволить MV быстро обновлять данные, изменяя только измененные данные. Однако различные условия не позволяют MV использовать журнал и поэтому требуют полного обновления. Oracle реализовал полное атомарное обновление в виде удаления и вставки каждой записи. Это происходит даже в том случае, если в конечном итоге данные не изменяются.

Есть ли способ сделать эту репликацию разумной в отношении генерации повторов ? MERGE, за которым следует DELETE, запрашивает источник дважды. Стоит ли массово собирать данные, чтобы выполнить BULK MERGE и DELETE? Есть ли способ лучше?

Обновить:

Я исследовал использование глобальной временной таблицы в качестве промежуточной области. Хотя они используют меньше половины повторов, они все равно используют много.

Это просто предназначено для демонстрации повторного использования различных insertопераций, а не для ответа на весь вопрос. Результаты на моем 10g экземпляре не являются на 100% детерминированными, но общая картина оставалась неизменной каждый раз, когда я пробежал.

Для кучи таблиц я не знаю, почему insert /*+ append */генерируется больше повторов.

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

контрольная работа:

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

результат:

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                   

Хороший вопрос. Я "решил" эту проблему для моей ситуации некоторое время назад, делая MV и любые индексы на них NOLOGGING. Не было никакого смысла в моей ситуации - в любом случае я делал полное обновление представления, зачем мне повторять?