[oracle_br] Re: Agendamento View Materializada
Opa : bom, quando vc diz "cabeçalho" na verdade vc quer se referir ao DDL de criação da view materializada, ao CREATE MATERIALIZED VIEW em si, certo ? View não tem "cabeçalho" nenhum... Então, vc tem dois tipos de REFRESH automático, o REFRESH ON COMMIT (que atualiza a view materializada sempre que houver um COMMIT) e o REFRESH com cláusula START WITH + NEXT (que atualiza baseado num Período de tempo que vc indica) : a primeira coisa vc tem que considerar para o REFRESH ON COMMIT é o overhead em CADA transação (pois o COMMIT só termina depois de refrescar a(s) vm(s) , e para o REFRESH auto-programado com cláusula de NEXT é que nem sempre é possível/viável vc ter a view "desatualiza" enquanto não chega a data/hora do refresh... OU SEJA, para as views que teu cliente PRECISA que sejam sempre 100% atualizadas ele TEM que mensurar e ter capacidade para suportar o tempo de COMMIT alongado, E para as views que suportem operação com dados defasados por um período, ele TEM que definir na criação da vm qual seria esse período... PODEM haver casos onde os dados só precisam estar atualizados com o dia anterior, digamos, aí vc bota pra refrescar á noite, E podem ter casos onde isso não é viável Varia... Respondendo, então , isso posto : a) absolutamente NÂO EXISTE PADRÃO pra isso, cada caso é um caso, é o seu cliente que tem que mensurar para quais vms ele suporta overhead, para quais pode haver alguma defasagem NÂO EXISTE PADRÃO, é sempre baseado no levantamento com o Cliente... b) depende do caso : http://oraclehack.blogspot.com.br/2013/02/create-fast-refreshable-materialized.html por exemplo mostra uma query complexa do tipo clássico (ie, usa funções no WHERE ou faz JOIN) que pôde ter a condição de FAST REFRESH ativada com o recurso de ROWID, mas isso (Óbvio) não é solução para qualquer tipo de refresh fast em SQLs complexos Não tem jeito, a resposta TEM que ser DEPENDE... c) sim, para os casos em que é viável REFRESH programado e/ou ON COMMIT, é Claro que é melhor pro cliente que o próprio banco já faça o necessário, é um trabalho a menos pra ele... []s Chiappa
Re: [oracle_br] Agendamento View Materializada
Rafael Primeiro, acredito que voce tem que informar aqui, qual o critério para atualização das V. Materializadas (por dia, horas, por commit na tabelas, exclusão de dados) ? Já criei v. materializadas que na sua criação, indicam qual a forma de atualização, exemplo (atualização a cada commit na tabela): --- create materialized view mv2 refresh fast on commit ENABLE QUERY REWRITE as select t_key , count(*) as row_count , count(amt) as amt_count from t2 group by t_key ; -- Segue abaixo algumas possibilidades para indicar a forma de atualização via cabeçalho: create materialized view nome_visão [build [deferred | immediate]] [refresh [complete | fast | force] [on commit | on demand]] [start with date] [next date]] [for update] [[enable | disable] query rewrite] as select Um item importante é deixar o comando: ENABLE QUERY REWRITE ... que permite ao otimizador reescrever queries, que podem se beneficiar da V. Materializada. Neto Em 22 de junho de 2016 17:36, Rafael Mendonca raffaell.t...@yahoo.com [oracle_br] escreveu: > > > Cenário: > > Oracle 11.2.0.4 Enteprise Edition + grid infraestructure(ASM) standalone > server > AIX 64 bits > > > Senhores, tenho algumas dúvidas em relação aos agendamentos das views > materializadas e gostaria da ajuda de vocês. > > Estou em um cliente que possui centenas de MVs. Para **CADA** MV os > desenvolvedores deste cliente pede para o DBA criar um JOB, um PROGRAM, um > SCHEDULER para executar uma PROCEDURE com o código de REFRESH da MV, ou > seja, todos os refreshes de MV's são feitas por DBMS_SCHEDULER. > > Como nunca tive muito convívio com MV's, sei que existe a possibilidade no > próprio cabeçalho da view materializada ser configurado o período de > atualização de acordo com a sua necessidade: Por commit, por demanda, por > agendamento (horario) etc, o TIPO de ATUALIZAÇÃO: FAST, FULL etc. > > O que eu quero evitar em minha base de dados é que o CLIENTE perca a mania > de estar sempre precisando criar um JOB/PROGRAM/SCHEDULER/PROCEDURE para o > agendamento do REFRESH da view e comece a ser feito no próprio cabeçalho da > view. > > a) Vocês seguem quais padrões para tal? > > b) Existe a possibilidade de realizar um REFRESH no modo FAST sendo uma > view do tipo complexa? > > c) Vocês concordam com a minha ideia de evitar essa gama de criação de > objetos para uma view ser atualizada? > > > Fico no aguardo dos comentários. > > :) > > > > > > > > > > >
[oracle_br] Agendamento View Materializada
Cenário: Oracle 11.2.0.4 Enteprise Edition + grid infraestructure(ASM) standalone server AIX 64 bits Senhores, tenho algumas dúvidas em relação aos agendamentos das views materializadas e gostaria da ajuda de vocês. Estou em um cliente que possui centenas de MVs. Para **CADA** MV os desenvolvedores deste cliente pede para o DBA criar um JOB, um PROGRAM, um SCHEDULER para executar uma PROCEDURE com o código de REFRESH da MV, ou seja, todos os refreshes de MV's são feitas por DBMS_SCHEDULER. Como nunca tive muito convívio com MV's, sei que existe a possibilidade no próprio cabeçalho da view materializada ser configurado o período de atualização de acordo com a sua necessidade: Por commit, por demanda, por agendamento (horario) etc, o TIPO de ATUALIZAÇÃO: FAST, FULL etc. O que eu quero evitar em minha base de dados é que o CLIENTE perca a mania de estar sempre precisando criar um JOB/PROGRAM/SCHEDULER/PROCEDURE para o agendamento do REFRESH da view e comece a ser feito no próprio cabeçalho da view. a) Vocês seguem quais padrões para tal? b) Existe a possibilidade de realizar um REFRESH no modo FAST sendo uma view do tipo complexa? c) Vocês concordam com a minha ideia de evitar essa gama de criação de objetos para uma view ser atualizada? Fico no aguardo dos comentários. :)
