ORACLE MATERIALIZED VIEWS

CONCEITOS GERAIS
Views Materializadas são objetos do usuário (subordinados a um schema) que podem
ser usados para sumariar, pré calcular, replicar e distribuir dados.

Em ambientes de Data Warehouse as views materializadas são usadas para pré-cálculo e

armazenamento de dados agregados tais como totais e médias. Também podem ser
usadas para pré calcular joins com ou sem agregações.

O Otimizador por Custo pode utilizar as views materializadas para aumentar a

performance das consultas reconhecendo, automaticamente, quando uma view
materializada pode ser usada para atender a uma requisição. O Otimizador,
transparentemente, reescreve a consulta para usar a view materializada. Nesta situação,
as consultas são direcionadas para as views materializadas em vez das tabelas detalhe
originais.

Em ambientes distribuídos, as views materializadas (também chamadas de snapshots)

são usadas para replicação de dados e para sincronismo de atualizações nos diversos
sites.

Em ambientes de computação móvel, as views materializadas são usadas para download

de um subconjunto dos dados residentes em um ambiente central, com recarga periódica
e propagação das atualizações de volta para o ambiente centralizado.

O Oracle garante a manutenção dos dados em uma view materializada através de

atualizações dos dados após as alterações terem sido efetivadas nas tabelas originais.

O método de atualização (refresh) pode ser incremental (fast refresh) ou completo. Para
o método incremental haverá a necessidade de criação de um log (materialized view
log) para armazenamento das alterações feitas para as tabelas originais.

A atualização das views materializadas poderá ser feita tanto sob demanda quando em
intervalos de tempos previamente definidos. Quando uma view materializada reside no
mesmo site de suas tabelas originais, sua atualização poderá ocorrer quando uma
transação efetivar (commit) suas modificações para as tabelas originais.

COMANDOS DE DDL PARA VIEWS MATERIALIZADAS

SINTAXE CREATE MATERIALIZED VIEW

Description of the illustration create_materialized_view.gif

(physical_properties::=, scoped_table_ref_constraint ::=,

materialized_view_props::=, physical_attributes_clause::=,
create_mv_refresh::=, subquery::=)

physical_properties::=
Description of the illustration physical_properties.gif

(segment_attributes_clause::=, table_compression ::=,

index_org_table_clause::=)

materialized_view_props::=

Description of the illustration materialized_view_props.gif

(column_properties ::=, table_partitioning_clauses ::=--part of CREATE

TABLE syntax, parallel_clause::=, build_clause::=)

scoped_table_ref_constraint ::=

Description of the illustration scoped_table_ref_constraint.gif

index_org_table_clause::=
Description of the illustration index_org_table_clause.gif

(mapping_table_clause: not supported with materialized views,

key_compression::=, index_org_overflow_clause::=)

key_compression::=

Description of the illustration key_compression.gif

index_org_overflow_clause::=

Description of the illustration index_org_overflow_clause.gif

(segment_attributes_clause::=)

create_mv_refresh::=
Description of the illustration create_mv_refresh.gif

segment_attributes_clause::=

Description of the illustration segment_attributes_clause.gif

(physical_attributes_clause::=, logging_clause::=)

physical_attributes_clause::=
Description of the illustration physical_attributes_clause.gif

(logging_clause::=)

logging_clause::=

Description of the illustration logging_clause.gif

table_compression ::=

Description of the illustration table_compression.gif

column_properties ::=

Description of the illustration column_properties.gif

(object_type_col_properties::=, nested_table_col_properties::=,
varray_col_properties::=, LOB_partition_storage::=, LOB_storage_clause::=,
XMLType_column_properties: not supported for materialized views)
object_type_col_properties::=

Description of the illustration object_type_col_properties.gif

(substitutable_column_clause::=)

substitutable_column_clause::=

Description of the illustration substitutable_column_clause.gif

nested_table_col_properties::=

Description of the illustration nested_table_col_properties.gif

(substitutable_column_clause::=, object_properties::=,
physical_properties::=--part of CREATE TABLE syntax,
column_properties ::=)

varray_col_properties::=
Description of the illustration varray_col_properties.gif

(substitutable_column_clause::=, LOB_parameters::=)

LOB_storage_clause::=

Description of the illustration LOB_storage_clause.gif

(LOB_parameters::=)

LOB_parameters::=
Description of the illustration LOB_parameters.gif

(storage_clause::=, logging_clause::=)

LOB_partition_storage::=

Description of the illustration LOB_partition_storage.gif

(LOB_storage_clause::=, varray_col_properties::=)

parallel_clause::=

Description of the illustration parallel_clause.gif

build_clause::=

ONDE:

schema – corresponde ao schema que conterá a view materializada. O default é o

schema corrente.

materialized_view / snapshot – indica o nome da view materializada a ser criada. O

ORACLE gera os nomes das tabelas e índices usados para manter a view materializada
adicionando um prefixo ou sufixo ao nome da view materializada. A ORACLE
recomenda que limitemos o tamanho do nome a 19 bytes para que os nomes gerados
não ultrapassem 30 caracteres.

physical_attributes_clause – estabelece valores para PCTFREE, PCTUSED, INITRANS

e MAXTRANS e informações de armazenamento.

TABLESPACE – especifica o tablespace no qual a view materializada será criada. Se

omitirmos esta cláusula, o ORACLE cria a view materializada no tablespace default.

LOB_storage_clause – especifica as características de armazenamento para os LOBs.

CLUSTER – cria a view materializada como parte do cluster especificado. Se

utilizarmos esta cláusula, não devemos usar os parâmetros referentes a
physical_attributes_clause ou TABLESPACE.

LOGGING | NOLOGGING – estabelece características de uso do ONLINE REDO

LOG para a gravação de informações na view materializada.

CACHE | NOCACHE – determina se e como o ORACLE armazena blocos recuperados

da view materializada no Buffer Cache.

partitioning_clauses – especifica que a view materializada é particionada e o método de

particionamento a ser usado.

PARALLEL | NOPARALLEL – indica a criação (ou não) da view materializada em

paralelo.

BUILD – especifica quando a View Materializada deve ser preenchida (populada).

IMMEDIATE – indica que a view será preenchida imediatamente após sua criação (é a
opção default).

DEFERRED – indica que a view será preenchida na próxima operação de REFRESH. O

primeiro Refresh é sempre completo. Até então, o estado da view é INVALID, desta
forma não pode ser usada para Query Rewrite.
Para ambientes de Data Warehouse, esta cláusula especifica que iremos refrescar a view
posteriormente usando a rotina DBMS_MVIEW.REFRESH.

ON PREBUILT TABLE – permite que façamos o registro de uma tabela existente para
uma view pré-inicializada. A tabela deve ter o mesmo nome da view que está sendo
criada.

A tabela existente mantém sua identidade como tabela e é, opcionalmente, mantida pelo
mecanismo de refresh de views materializadas (a fim de retratar as alterações realizadas
nas tabelas-detalhe correspondentes).

WITH REDUCED PRECISION – Indica que autorizamos a perda de precisão

proveniente do fato das colunas na view materializada ou nas tabelas não serem
exatamente iguais em relação à precisão retornada pelas colunas da query.

WITHOUT REDUCED PRECISION – determina que a precisão das colunas da tabela

ou da view materializada devem ser exatamente iguais à precisão retornada pela
subquery. Esta é a opção default. A operação falha se esta situação não for atendida.

RESTRIÇÕES:

A tempo de registro, a tabela deve refletir a materialização da subquery.

Cada alias de coluna na subquery deve corresponder a uma coluna na tabela nomeada.
A coluna correspondente deve ter os mesmos tipos.

Se usarmos esta cláusula não podemos especificar a constraint NOT NULL para
qualquer coluna não referenciada na subquery a menos que tenhamos especificado um
valor default para aquela coluna.

USING INDEX – especifica parâmetros para criação dos índices. Como restrição temos
que não é possível a especificação dos parâmetros PCTUSED e PCTFREE nesta
cláusula.

REFRESH – especifica como e quando o Oracle, automaticamente, refresca a view

materializada. Quando a(s) tabela(s) master são modificadas, o dado na view
materializada deve ser atualizado para assegurar que a view reflita de forma acurada o
dado presente na(s) tabela(s) master. Esta cláusula permitirá que especifiquemos não só
o momento, como também o modo como a atualização será realizada.

NOTA: Também podemos atualizar uma view materializada com a rotina

DBMS_MVIEW.REFRESH().

FAST – especifica uma forma de atualização rápida (incremental), que usa somente
atualização dos dados, os quais estão armazenados no log da view materializada.

Estes dados estão relacionados às tabelas originais. O log deve existir para que a
operação de Fast Refresh seja bem sucedida (a menos que usemos direct path load).
O ORACLE somente poderá realizar um Fast Refresh se todas as condições a seguir
forem verdadeiras:

A view materializada respeita as regras relativas a replicação.

A master table da view materializada tem um log (materialized view log) ou usamos
Direct Load Insert (neste caso o Oracle cria um Direct Loader Log automaticamente.
Nenhuma intervenção é necessária).

O log foi criado antes da view materializada ter sido refrescada ou criada.

COMPLETE – Especifica que a atualização da informação será completa, ou seja, uma

nova execução da query constitutiva da view materializada. Se especificarmos esta
opção o Oracle realiza uma atualização completa, mesmo que a parcial (Fast) seja
possível.

FORCE – Indica que se não for possível à realização de um Fast Refresh, deve ser
realizado um Complete Refresh. O Oracle decide se um Fast Refresh é possível a tempo
de execução. Esta é a opção default.

ON COMMIT – determina que a atualização (Refresh) ocorrerá, automaticamente,

quando a próxima operação de COMMIT ocorrer.

Esta cláusula é suportada apenas para Materialized Join Views e Materialized

Aggregate Views.

ON DEMAND – especifica que as views materializadas serão refrescadas quando o

usuário desejar, através da execução de uma das três rotinas do pacote DBMS_MVIEW.

Esta cláusula também especifica que um FAST REFRESH ocorrerá somente se

adicionarmos dados usando um método de carga direta.

START WITH – especifica uma expressão de data que determina o primeiro refresh
automático.

NEXT – especifica uma expressão de data para cálculo do intervalo entre os Refreshes
automáticos.

Tanto o valor de START WITH quanto o de NEXT devem ser avaliados para um
momento no futuro. Se omitirmos o valor START WITH, o Oracle determina a primeira
data através da expressão presente no Next aplicada sobre a data de criação da view
materializada.

Se especificarmos START WITH e omitirmos NEXT, o Oracle refresca a view

materializada somente uma vez. Se omitirmos ambos, o Oracle não refresca a view
materializada.

WITH PRIMARY KEY – especifica que uma view materializada baseada em Primary
Key será criada. Esta é a opção default e deve ser usada em todos os casos (exceto para
aqueles descritos no item WITH ROWID).
WITH ROWID – especifica que uma view materializada baseada em Rowid será criada.
Este tipo de objeto foi mantido para compatibilidade com versões anteriores à versão
8.0.

Podemos também usar este tipo de objeto para suportar views materializadas que não
incluam todas as colunas de primary key.

Para views materializadas baseadas em Rowid as seguintes restrições devem ser

respeitadas:

Devem estar baseadas em uma única tabela remota

Não podem conter funções de agregação ou a cláusula Distinct

Não podem conter as cláusulas Group By ou Connect By

Não podem conter Subqueries, Joins ou Operações de Conjuntos (Minus, Union, etc).

Não podem ser Fast Refreshed após uma reorganização da Master Table.

USING ROLLBACK SEGMENT – determina um segmento de rollback a ser usado

durante a operação de Refresh da view materializada.

Se especificarmos Default, o Oracle determinará, automaticamente, qual o segmento de

rollback a ser usado. Se especificarmos Master, indicamos que o segmento de rollback a
ser usado reside no Master Site. Se especificarmos Local, indicamos que o segmento de
rollback a ser usado reside no site remoto.

Se não especificarmos Master or Local, o Oracle usa o Local por default. Se não
especificarmos nenhum segmento de rollback, o Oracle escolhe qual usar.

NEVER REFRESH – suprime a atualização da view materializada.

FOR UPDATE – permite que a view materializada seja atualizada. Quando usado
juntamente com Advanced Replication, estas atualizações serão propagadas para o
Master.

QUERY REWRITE – especifica se a view materializada está apta a ser usada em query
rewrite.

ENABLE – habilita a view materializada para Query Rewrite. Esta cláusula está
desabilitada, por default.

Somente podemos habilitar esta opção se todas as funções do usuário presentes na view
materializada forem do tipo DETERMINISTIC.

Se usarmos variáveis Bind na query, esta não será usada pelo mecanismo de query
rewrite, mesmo que venhamos a habilitar esta opção.

Somente podemos habilitar query rewrite se o comando possuir apenas expressões

repetitivas, isto é, não podem ser incluídos Current_Time, User, Rownum, etc.

DISABLE – especifica que a view materializada não é elegível para uso pelo
mecanismo de query rewrite. Porém poderá ser refrescada.

AS subquery – especifica a query da view materializada. Quando criamos a view

materializada o Oracle executa esta query e coloca os resultados na view materializada.
Esta query corresponde a qualquer comando de SQL SELECT válido. Nem todas as
queries, porém, podem ser atualizadas usando o mecanismo Fast e nem todas são
elegíveis para Query Rewrite.

NOTAS:

O Oracle não executa a query imediatamente se especificarmos BUILD DEFERRED.

A Oracle recomenda que qualifiquemos cada uma das tabela da cláusula FROM com o
schema onde esta se encontra.

RESTRIÇÕES:

A query não pode selecionar tabelas ou views subordinadas ao usuário SYS.

Não podemos especificar a cláusula ORDER BY na subquery de uma view

materializada.

Views materializada com um Join ou com múltiplas Master Tables e um Group By não
podem selecionar dados de uma Index-Organized Table.

Não podem conter colunas do tipo LONG.

Se uma subquery faz referência a uma tabela temporária, não podemos criar uma log
para esta view materializada e não podemos especificar a cláusula Query Rewrite.

Se a cláusula FROM da view materializada fizer referência à outra view materializada,

devemos controlar a ordem de Refresh manualmente, ou seja, devemos refrescar a view
materializada sem dependência primeiro e, então a view materializada dependente, para
manter a integridade.

Se desejarmos criar uma view materializada para Query Rewrite:

A subquery não pode conter referências a ROWNUM, USER, SYSDATE, tabelas

remotas, seqüências ou funções de PL/SQL que leiam ou gravem no banco de dados ou
em variáveis de pacote.

Tanto a view materializada quanto as tabelas detalhe devem ser locais.

Não pode fazer referência a colunas do tipo Raw, Long Raw ou Refs (objetos).

A query deve ser composta de um único bloco, ou seja, não pode conter funções de
conjunto (Union, Minus, etc). A view materializada, no entanto, pode conter mais de
um bloco (Selects na cláusula From, Subselects na cláusula Where e Having).

Somente tabelas detalhe locais (ou views) podem ser usadas na query ou na definição de
uma view materializada.

Para que um texto de SQL possa ser candidato a Rewrite, as seguintes restrições são
aplicáveis:

A lista de objetos na cláusula FROM não pode conter múltiplas ocorrências da mesma
tabela ou view.

As listas das cláusulas SELECT e GROUP BY, se presentes, devem ser as mesmas na
query e na view materializada e devem conter apenas as colunas, isto é, não são
permitidas expressões nas colunas.

Operadores de agregação devem utilizar funções de agregação com parâmetros simples,

isto é, AVG (AVG(X)) ou AVG(X) + AVG(X) não são permitidos.

A cláusula WHERE deve conter somente Inner ou Outer Eqüijoins, que possam ser
conectados por ANDs. Ou seja, Ors e seleções em tabelas individuais não são
permitidas na cláusula Where.

As cláusulas Having e Connect By não são permitidas.

Se desejarmos otimizar o mecanismo de Query Rewrite, as regras a seguir também

devem ser aplicadas:

Não definir qualquer Nested Subquery ou Inline Views (Select na cláusula From).

Se especificarmos a cláusula GROUP BY, esta não deve conter funções de PL/SQL ou
expressões e, devemos especificar todas as colunas da cláusula Group By na lista de
seleção.

Todas as relações na lista FROM devem ser tabelas e elas devem ser distintas após
Synonym Resolution (ou seja, não fazer referência mais de uma vez à mesma tabela).

Se especificarmos Outer Joins para uma view materializada complexa, devemos listar
ambos os lados do Outer Join na lista da cláusula GROUP BY.

Devemos nos assegurar que cada expressão de agregação utilize uma função de
agregação com parâmetros simples (isto é não utilize uma expressão de agregação
dentro de outra).

PARÂMETROS PARA VIEWS MATERIALIZADAS

Para que as views materializadas possam ser utilizadas pelas características de

sumarização para o ambiente Data Warehouse, os seguintes parâmetros devem ser
preenchidos:

Warehouse Refresh
JOB_QUEUE_PROCESSES – Este parâmetro indica quantos processos background
(SNP) podem ser executados concomitantemente. Indiretamente determinará quantas
views materializadas podem ser refrescadas concorrentemente.

JOB_QUEUE_INTERVAL – Este parâmetro determina o intervalo de avaliação do

processo SNP. Indica de quanto em quanto tempo o processo background deve verificar
se existem jobs para execução na fila.

UTL_FILE_DIR – Determina o diretório onde o Refresh Log será gravado. Se não for
especificado, nenhum log será gerado.

Query Rewrite

QUERY_REWRITE_ENABLE = TRUE – Este parâmetro habilita o mecanismo de re-

escrita da query.

QUERY_REWRITE_INTEGRITY = ENFORCED ou TRUSTED ou

STALE_TOLERADE – Este parâmetro determina como o nível de atualização da view
materializada deve estar para que esta possa ser eleita pelo mecanismo de re-escrita da
query. Este parâmetro é opcional.

COMPATIBLE – Este parâmetro deve estar preenchido com 10.1 ou superior.

Advisor Workload (parâmetros obrigatórios)

ORACLE_TRACE_ENABLE = TRUE – Habilita o mecanismo de Trace.

ORACLE_TRACE_FACILITY_NAME = ORACLESM – Determina o nome do

mecanismo que fará a coleta.

ORACLE_TRACE_FACILITY_PATH = ?/otrace/admin/cdf – Determina o diretório

onde os arquivos de definição do Trace estão localizados.

Advisor Workload (parâmetros recomendados)

ORACLE_TRACE_COLLECTION_NAME = ORACLSM – Determina o nome do
arquivo do mecanismo Trace Collection.

ORACLE_TRACE_COLLECTION_PATH = ?/otrace/admin/cdf – Determina o

diretório onde os arquivos de coleta estão armazenados.

ORACLE_TRACE_COLLECTION_SIZE = 0 – Determina o tamanho inicial do

arquivo de coleta.

Paralelismo (Parâmetros Recomendados)

PARALLEL_MAX_SERVERS – Deve ser alto para sempre possibilitar o paralelismo.

SORT_AREA_SIZE – Deve ser menor que Hash_Area_Size.

OPTIMIZER_MODE – Deve ser igual a Choose (otimização por custo).

OPTIMIZER_PERCENT_PARALLEL – Deve ser igual a 100.

Privilégios para Views Materializadas

Para que as views materializadas possam usar a opção de QUERY REWRITE, o
usuário criador da view deve ter um dos seguintes privilégios de sistema: QUERY
REWRITE ou GLOBAL QUERY REWRITE.

Exemplos
O comando a seguir cria uma view materializada de nome MV_POR_VENDEDOR que
calcula as vendas por vendedor.

DROP SNAPSHOT MV_POR_VENDEDOR;

CREATE MATERIALIZED VIEW MV_POR_VENDEDOR

PCTFREE 0 TABLESPACE USERS
STORAGE (INITIAL 16K NEXT 16K PCTINCREASE 0)
BUILD DEFERRED
REFRESH COMPLETE ON DEMAND
ENABLE QUERY REWRITE
AS SELECT V.CD_VENDEDOR, SUM(V.VL_VENDA) SOMA
FROM VENDAS V
GROUP BY V.CD_VENDEDOR

COMMIT;
EXECUTE DBMS_MVIEW.REFRESH('MV_POR_VENDEDOR', 'C', NULL, TRUE,
FALSE, 1, 0, 0, TRUE)
SELECT COUNT(*) FROM MV_POR_VENDEDOR;

A view materializada não contém qualquer dado porque foi determinado que o método
de construção é DEFERRED.

Quando ela for refrescada, será realizado um Refresh completo. Após esta etapa, esta
view materializada poderá ser usada com Query Rewrite.

A view materializada é preenchida com dados imediatamente após sua criação em

função da escolha do método IMMEDIATE e está disponível para uso pelo mecanismo
de Query Rewrite.

A cláusula ON DEMAND foi omitida da especificação da cláusula Refresh uma vez

que é a opção default.

Desta forma não haverá Refresh até que uma requisição manual seja informada.
A view materializada é preenchida imediatamente com dados porque o método é
IMMEDIATE e ela fica disponível para ser usada pelo mecanismo de Query Rewrite.

O método de Refresh é FAST é permitido porque as funções de agregação COUNT e

SUM foram incluídas para suportar o Fast Refresh de outras funções de agregação..

A view materializada não é preenchida com dados imediatamente (DEFERRED) e não

está disponível para Query Rewrite porque a cláusula correspondente não foi
mencionada. O método de Refresh é Force, que indica que o método de Refresh mais
adequado será escolhido pelo Oracle a tempo de execução da operação.

A view poderá conter uma ou mais funções de agregação (SUM, AVG, VARIANCE,
etc) e a cláusula GROUP BY. As funções de agregação poderão envolver expressões
em colunas, tais como SUM (a*b).

Se esta view materializada for refrescada de forma incremental (FAST), ela deverá
incluir uma tabela de log associada à tabela detalhe que contenha a cláusula
INCLUDING NEW VALUES e contenha todas as colunas referenciadas na definição
da query da view materializada.

Deve existir um Materialized View Log para cada tabela detalhe envolvida.

As rowids de todas as tabelas detalhe devem estar presentes na lista de SELECT da

query da view materializada.

Se houverem Outer Joins, deve existir uma constraint de unicidade sobre as colunas
Join da Inner Table.

Se alguma das restrições for violada, a view materializada deve ser criada com a opção
de Refresh Force. Se uma das tabelas não atende aos critérios, mas as outras atendem, a
view materializada poderá ser refrescada de forma incremental, mas somente para as
tabelas para as quais todos os critérios são satisfeitos.

Para Data Warehouses utilizando um esquema Star se houver pouco espaço, podemos
incluir o rowid apenas da tabela Fato uma vez que esta tabela será mais freqüentemente
atualizada. Neste caso podemos especificar a opção FORCE para a criação da view
materializada.

O log da view materializada deve conter o rowid da master table. Não é necessária a
adição de outras colunas.

Refresh do tipo incremental (FAST) é possível para views materializadas contendo joins
após qualquer tipo de operação de DML para as tabelas básicas (carga direta ou
INSERT, UPDATE ou DELETE).

Uma view materializada contendo somente joins pode ser definida com REFRESH ON
COMMIT ou ON DEMAND. Após um refresh ON COMMIT devemos avaliar os
arquivos de alerta e trace do banco de dados para verificar se ocorreu algum erro
durante a operação.
Para obtermos uma melhor performance durante a operação de Refresh, é recomendado
que o usuário crie índices nas colunas da view materializada que armazenam os rowids
da tabela Fato.

OUTRAS CARACTERÍSTICAS DE VIEWS MATERIALIZADAS

Registrando uma view materializada pré-existente
Em alguns ambientes Data Warehouse já existem implementações de views
materializadas em tabelas normais.

Apesar desta solução possuir as vantagens relativas à performance trazida pelas views
materializadas não torna possível a re-escrita do SQL das aplicações e nem tem a
habilidade de atualização Fast.

Em função desta situação e, uma vez que as views materializadas podem ser
extremamente grandes (uma reconstrução poderia ser muito custosa), o Oracle permite
que registremos uma tabela como view materializada usando a cláusula PREBUILT
TABLE.

Com esta solução a view materializada poderá ser utilizada pelos mecanismos de
Refresh e Query Rewrite (para que ela seja utilizada pelo mecanismo de Query Rewrite,
o parâmetro QUERY_REWRITE_INTEGRITY devem receber, pelo menos, o nível
TRUSTED).

Quando efetuamos um DROP em uma view materializada que tenha sido criada baseada
em uma tabela pré-existente, apenas a view é removida, a tabela continua criada no
banco de dados.

Quando uma tabela pré-existente é registrada, o parâmetro

QUERY_REWRITE_INTEGRITY deve estar preenchido com o valor
STALE_TOLERATED pelo menos, uma vez que a view materializada é marcada como
STALE.

A tabela deve refletir a materialização da query definida no momento do registro como

uma view materializada e cada coluna na definição da query deve corresponder a uma
coluna na tabela com o mesmo tipo de dado. Podemos, no máximo, usar a cláusula
WITH REDUCED RESOLUTION a fim de permitir que a precisão das colunas
correspondentes seja diferente.

No exemplo anterior observamos que a tabela e a view possuem, exatamente, o mesmo

nome. É desta forma que efetuamos o registro, isto é, indicamos a qual tabela pré-
existente a view corresponde.

A tabela, no entanto, mantém sua identidade como tabela e pode conter colunas que não
estão referenciadas na definição da query da view materializada, chamadas de
unmanaged columns.

Se houver inserção de linhas durante uma operação de refresh, cada coluna não
correspondente (unmanaged columns) de uma linha é preenchida com seu valor default,
desta forma, estas colunas não podem ter sido definidas com a restrição NOT NULL, a
menos que elas possuam valor default especificado.

Este tipo de coluna (unmanaged columns) não é suportado em views materializadas

originárias de agregações em uma única tabela ou em views materializadas contendo
apenas joins.

Particionamento de Views Materializadas

O particionamento é similar ao particionamento de uma tabela. Para views
materializadas os benefícios podem ser estendidos ao momento do Refresh, que poderá
ocorrer em paralelo.

Uma situação ideal para utilização de particionamento em views materializadas é

quando a view contém um subconjunto de dados, que é obtido pela definição de uma
expressão do tipo WHERE dt_venda < ‘01/10/1999’ no SELECT da view
materializada.

Neste caso a view materializada será criada com informações restritas ao exato período
informado, o que traz restrições à utilização da view.

Para contornarmos este problema, o particionamento pode ser feito de tal forma que a
view materializada não contenha a restrição de data, tornando seu uso mais amplo pelas
aplicações.

Existem duas possibilidades de particionamento para views materializadas:

Particionamento da view materializada – este formato envolve a definição de uma view

materializada com as cláusulas padrões de particionamento do Oracle.

Particionamento de uma tabela pré-existente – neste caso as cláusulas de

particionamento estão definidas na tabela previamente construída.

Indexação para Views Materializadas

As duas principais operações sobre views materializadas são a execução de uma
consulta e o processo de atualização e, cada uma destas operações possui requerimentos
de performance diferentes.

A operação de Fast Refresh necessita obter um conjunto de linhas que sejam

compatíveis com as chaves da view e será mais eficiente se existir um índice
concatenado que englobe todas estas colunas.

A operação de Query, por outro lado, pode necessitar de acesso a qualquer subconjunto
das colunas chaves da view materializada e pode necessitar de Joins e agregações sobre
um subconjunto destas colunas, conseqüentemente, a pesquisa será mais eficiente se
houverem índices bitmap simples (de uma única coluna) definidos em cada chave da
view materializada.

Uma opção para indexação é a definição de um índice local do tipo unique que contenha
todas as chaves da view materializada e um índice bitmap para cada coluna individual
que seja chave da view se houver espaço em disco e o tempo de Refresh permitir.

No caso da view materializada conter joins somente, se a opção de Fast Refresh estiver
habilitada, é altamente recomendado que os índices sejam criados nas colunas que
contenhas os rowids para incremento da performance da operação de Refresh.

Regras para criação de Views Materializadas - Data Warehouse

A determinação de que views deveriam ser criadas objetivando melhorias em termos de
performance pode ser obtida com o uso da rotina RECOMMEND_MV do pacote
DBMS_OLAP.

Esta rotina produz uma lista das views materializadas que o Oracle recomenda baseado
em informações estatísticas e no uso do banco de dados. Este pacote somente
recomenda views materializadas que tenham agregações em múltiplas tabelas.

Se desejarmos criar nossas próprias views materializadas sem a ajuda da ferramenta de

análise da Oracle, devemos seguir as regras abaixo:

Em vez de definirmos múltiplas views materializadas baseadas na mesma tabela com a

mesma cláusula GROUP BY, mas com diferentes agregações, defina uma única view
materializada incluindo todas as agregações.

Se a view materializada inclui a agregação AVG(X), também inclua a agregação

COUNT(X) para suportar Refresh incremental. Da mesma forma se VARIANCE ou
STDDEV estiver presente, inclua COUNT e SUM para que seja possível Fast Refresh.