ORACLE MATERIALIZED VIEWSCONCEITOS 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 RefreshJOB_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 MaterializadasPara 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.

ExemplosO 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 MATERIALIZADASRegistrando uma view materializada pré-existenteEm 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 MaterializadasO 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 MaterializadasAs 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 WarehouseA 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.