Veja lá que CONCEITUALMENTE no RDBMS Oracle é virtualmente IMPOSSÍVEL vc não gerar redo algum pois, como sabemos, além de servir para a recuperação em caso de falha, o undo gerado para consistência de leitura - o RDBMS Oracle ** nunca faz leitura suja, então Qualquer DML gera UNDO - implica em geração de redo para as estruturas internas do RDBMS que controlam transações... Da mesma forma, o refresh de uma mv Necessariamente implica em geração de redo para as tabelas/índices internos que controlam a mv em si.... Assim, o que o atributo de NOLOGGING faz é DIMINUIR o redo - impossibilitar geração de redo é como eu disse IMPOSSìVEL, ok ? Isso posto, PROVAVELMENTE o que deve estar pegando no seu caso pode ser que : OU a mv em si está LOGGING (de repente a tablespace está com NOLOGGING mas a mv não foi criada assim), e/ou vc deve estar pedindo um REFRESH completo (o que implica em montes de dados a transacionar) , E/OU vc está usando grupo de refresh E/OU vc não está setando o atomic_refresh=>false ....
Assim, EXTRAIA o DDL da m para ter certeza que ela está como nologging, analise se é viável/possível refresh incremental , E veja (vide https://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:15695764787749#7066764400346113957 para um exemplo) se é o caso de setar atomic_refresh.... Adicionalmente, não se aceita achismo, esse seu "APARENTEMENTE" não tá legal : eu diria para vc, como parte da investigação, colocar na rotina que refresha a mv (vc não diz mas ao que entendo é isso que vc tem, é um job que faz refresh a cada 6 minutos) uma instrumentação , gravando/registrando o valor da estatística REDO SIZE antes e depois do refresh (assim vc saberá EXATAMENTE quanto redo está sendo gerado) .... []s Chiappa OBS : a) SE vc tiver índices na mv o nologging não vai funcionar adequadamente (índices SEMPRE são atualizados linha-a-linha, gerando redo) e b) se vc estiver usando standby físico, CERTAMENTE o database deve estar em modo de FORCE LOGGING, aí Também o NOLOGGING não irá funcionar adequadamente
