Menu de navegação

[ramasineParticipante]

Por questões conceituais e garantia de integridade dos dados o Oracle após aberto um cursor para um ou mais objetos, todas as alterações efetuadas nesses objetos são armazenadas nos segmentos de UNDO (rollback), isso nos garante que se eu inicio um Report as 13:00PM e ele só termina as 14:00PM todas as informações vão estar com a posição da hora de inicio da transação ou seja as 13:00PM, independentemente se os registros foram alterados das 13:00PM as 14:00PM. Bom até aí OK!! RS

Possuo a seguinte estrutura de materialized views (Snapshots).

– Todas as mviews pertencem ao mesmo refresh group (View_Datamart).
– Executado o refresh pelo job dbms_refresh.refresh(‘”GENDM01″.”VIEW_DATAMART”‘);
– Tempo total de execução 4:30 min intervalo de 10 min, refresh complete em todas elas.

Nesse ponto é que as coisas começam a ficar interessantes: ahhh!!!

1) Durante a criação do refresh group foi estabelecido a ordem de refresh das mviews para que justamente possa se fazer o refrescamento de forma que a mview de resultado seja a ultima a ser refrescada.

2) O job executa de forma normal não apresentando nenhum erro porém se nota um elevado consumo de UNDO e consequentemente uma geração elevada de archived logs, a princípio a o undo deveria ser alguma interface da aplicação que estaria indevidamente a ser executa (coisa normal aqui) e os archived logs seriam oriundos dessa interface errada.

3) Prossegui com algumas verificações principalmente observando o consumo de undo e a geração de archives.

4) Por segurança as Mviews foram transferidas para uma tablespace em nologging para evitar a geração de archives no momento do refresh.

5) Para meu espando essa alteração não teve nenhum efeito, continuando a ter uma geração de archives alta assim como o consumo de elevado de UNDO, o que a principio não se justificava.

6) Iniciei uma validação em todo o processo e obtive a seguinte informação:

select mview_name,to_char(last_refresh_date,’DD/MM/YYYY hh24:mi:ss’) from dba_mviews where mview_name Like ‘MV_R_AG%’

Mview_name Last_Refresh_Date
MV_R_AGALLSL001_NO_AGG 14/08/2009 11:28:35
MV_R_AGTTV001_NO_AGG 14/08/2009 11:28:35
MV_R_AGVOC001_NO_AGG 14/08/2009 11:28:35
MV_R_AGWC2001_NO_AGG 14/08/2009 11:28:35
MV_R_AGITV001_NO_AGG 14/08/2009 11:28:35
MV_R_AGLNT001_NO_AGG 14/08/2009 11:28:35
MV_R_AGLUS001_NO_AGG 14/08/2009 11:28:35
MV_R_AGNPT001_NO_AGG 14/08/2009 11:28:35
MV_R_AGBDP001_NO_AGG 14/08/2009 11:28:35
MV_R_AGCAC001_NO_AGG 14/08/2009 11:28:35
MV_R_AGCMV001_NO_AGG 14/08/2009 11:28:35
MV_R_AGCOM001_NO_AGG 14/08/2009 11:28:35
MV_R_AGBCP001_NO_AGG 14/08/2009 11:28:35
MV_R_AG1CL001_NO_AGG 14/08/2009 11:28:35
MV_R_AG1TT001_NO_AGG 14/08/2009 11:28:35
MV_R_AG2LF001_NO_AGG 14/08/2009 11:28:35

O que comprova que quando se faz um refresh por refresh group todas as mviews constantes no processo são refrescadas de forma simultânea que no meu caso é muito complicado pois como explicitado acima o processo de garantia dos dados passa a armazenar a informação das 15 Mviews que constam no processo e o refresh para a view resultado passa não ser feito com os dados atuais e sim com os dados anteriores.
O que se resolve colocando o refresh da mview de resultado em um segundo passo no refresh e não no refresh group das anteriores.

A ajuda que peço é apenas uma segunda opinião sobre o resultado, ele so estaria errado se a data inserida no last_refresh_date for a data de termino do processo o que vai contra a todos os processos normais de log de datas do Oracle, que normalmente guarda a data inicial.

Posso fazer o teste colocando a data fixa no Job e verificando a data informada mas como este procedimento gera um certo impacto na aplicação ainda não foi possível executar novamente.

Uii!!

[Rodrigo AlmeidaParticipante]

Marcelo,

A coluna last_refresh_date reflete justamente a data da última atualização do GRUPO da MV, como as MVs pertencem ao mesmo grupo, todas vão ter o mesmo horário.

Diferente se executar uma isoladamente.

Abraços,

[vieriParticipante]

Cara vc está se espantando com coisas normais..
ARCHIVE => BI gerá muito… aqui na empresa coisa de 30G,
undo usa muito!! tenho undo de 50G.

Acho que vc está assustado .. exige mto do banco é assim mesmo…
mas estás mviews em 10 em 10 minutos é cruel !!!!!!!

30 em 30 min tá de bom tamanho

[vieriParticipante]

archive 30 gb por dia !!

nologging minimiza mas não impede a geração!

[ramasineParticipante]

Alguem mais? Alguma opinião ? rs

[Rodrigo AlmeidaParticipante]

Marcelo,

Tenho mais uma opinião, trabalhei em alguns ambientes de BI, DW para ser mais exato, e sempre trabalhamos com o DW em NOARCHIVELOG, justamente para não ter esse consumo de ARCHIVES.

Pois “teoricamente” nos ambientes de DW, só se tem INSERT (DELETE e UPDATE) é raro e com muita restrição! Mas existe para alguns processos.

MV é muito utilizado nesses ambientes, porém, necessariamente não precisa deixar eles e sua respectiva tablespace em LOGGING, pois a MV irá construir uma PRE BUILD TABLE sobre um SELECT que está em outra base, então se perder as MVS, basta reconstruir-las. (Pode demorar prakas, mas não há perda de dados)!

Agora, mais dicas sobre DW que possa impactar nas suas MVs, e verificar se as suas MVS estão trabalhando com o recurso de replicação, ou seja, MV LOG e MV Fast Refresh!, ou seja, uma MV LOG para armazenar todos os dados NOVOS das tabelas e replicar via FAST RESFRESH para a sua MV de origem, reduz o tempo e consequentemente os ARCHIVES.

Abraços,

[Autor]

Posts