Início / dba / Perguntas / 72826
Accepted
a_horse_with_no_name
Asked: 2014-08-01 00:31:07 +0800 CST

Por que descartar um MVIEW aciona uma atualização completa?

  • 772

Acabei de criar uma visão materializada no Oracle, mas percebi que usei o script errado, então queria descartar o MVIEW novamente.

O MVIEW foi criado com uma declaração como esta:

create materialized view foobar
  refresh start with trunc(sysdate) + 1/8  next sysdate + interval '8' hour
as
select ...
from ...;

A criação levou algum tempo.

Agora, depois de perceber que era o script errado, executei:

drop materialized view foobar;

Que estava funcionando por algum tempo também. Primeiro pensei que poderia ser devido a alguns bloqueios ou outras sessões bloqueando isso, mas não: quando perguntei v$session, vi que minha dropdeclaração realmente acionou uma atualização completa do mview:

NOME DE USUÁRIO | SID | Nº DE SÉRIE | PROGRAMA | ESTADO | SQL_ID | SQL_TEXT
----------+------+---------+---------------------- ----+--------+---------------+-------------------- -------------------------------------------------- ---
MEU_USER | 294 | 29131 | oracle@hostname (J002) | ATIVO | 6snjgrzbtynyc | INSERT /*+ BYPASS_RECURSIVE_CHECK */ INTO "MY_USER","FOOBAR" select .....

E, de fato, drop materialized viewfuncionou quase ao mesmo tempo que o create.

Então, minha pergunta: por que o Oracle acionaria uma atualização completa quando eu solto uma visualização materializada?

Ambiente: Oracle 11.2.0.3 64 bits

PS: Acho que o alias indexed-viewde materialized-viewestá errado. Embora ambos façam referência ao mesmo conceito subjacente, são nomes distintos usados ​​pela Microsoft e pela Oracle. Alguém interessado em visualizações materializadas no Oracle provavelmente não está interessado em visualizações indexadas no SQL Server. Mas não sei como esse alias pode ser removido

oracle materialized-view

1 respostas

  1. Best Answer

    Depois de executar alguns testes em um ambiente isolado, parece que Raj está certo: o trabalho de atualização em segundo plano que vi enquanto esperava pelo DROPnão foi acionado pelo arquivo DROP. Tanto quanto eu posso dizer, isso foi causado pelas configurações de atualização fornecidas durante a criação do mview.

    Parece que

    refresh start with trunc(sysdate) + 1/8  next sysdate + interval '8' hour

    junto com o implícito build immediatefaz com que o mview seja atualizado durante a criação e novamente imediatamente após o término da criação.

    Aparentemente start with trunc(sysdate) + 1/8causa isso. ao correr

    create materialized view foobar 
   BUILD DEFERRED
   refresh start with trunc(sysdate) + 1/8  next sysdate + interval '8' hour
as
select ...
from ...;
    A createinstrução termina rapidamente e, quando examino as sessões ativas, vejo uma sessão em segundo plano que faz a atualização.

    • 1

relate perguntas