Limiter le rétablissement pour une actualisation complète de la vue matérialisée ou un équivalent manuel

Un journal de vue matérialisée ^(MV) peut être utilisé pour permettre à un MV d'effectuer une actualisation rapide qui ne modifie que les données modifiées. Cependant, diverses conditions empêchent le MV d'utiliser le journal et nécessitent donc une actualisation complète. Oracle a implémenté une actualisation atomique complète en tant que suppression et insertion de chaque enregistrement. Il le fait même s'il n'y a finalement aucun changement dans les données.

Existe-t-il un moyen de rendre cette réplication intelligente en ce qui concerne la génération de redo ? Un MERGE suivi d'un DELETE nécessite d'interroger la source deux fois. Vaut-il la peine de collecter les données en bloc pour effectuer une fusion et une suppression en bloc? Y a-t-il une meilleure façon?

Mettre à jour:

J'ai exploré l'utilisation d'une table temporaire globale comme zone de transit. Bien qu'ils utilisent moins de la moitié de la répétition, ils en utilisent encore beaucoup.

Ceci est juste destiné à démontrer l'utilisation de refaire de diverses insertopérations plutôt que de répondre à la question entière. Les résultats sur mon instance 10g ne sont pas 100% déterministes, mais la vue d'ensemble est restée la même à chaque fois que j'ai parcouru.

Pour les tables de tas, je ne sais pas pourquoi elles ont insert /*+ append */généré plus de redo.

banc d'essai:

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

tester:

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

résultat:

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                   

Bonne question. J'ai "résolu" ce problème pour ma situation il y a quelque temps en faisant les MV et tous les index sur eux NOLOGGING. Cela ne servait à rien ma situation - je faisais quand même un rafraîchissement complet de la vue, pourquoi aurais-je besoin de refaire?