Oracle Materialized Views: Gerenciando em standby lógicos no Oracle

Um dos principais recursos da versão Enterprise do banco de dados Oracle é o Data Guard. Essa feature é a principal ferramenta para disponibilizar o ambiente de alta disponibilidade oferecido pela Oracle e, em conjunto com o Real Application Cluster, nos permite disponibilizar o banco de dados para os usuários mesmo quando ocorre um problema grave no banco de dados principal.

Além de providenciar alta disponibilidade para bancos de dados, podemos utilizar a feature de Data Guard para criarmos bancos de dados específicos para relatórios evitando que consultas executadas impactem na performance do banco de dados principal e/ou com informações históricas, permitindo remover dados que não são mais importantes para o banco principal mas, mesmo assim, poderão ser lidas em futuras consultas. Um bom exemplo seria configurar o banco de dados standby para não replicar o comando alter table drop partition.

Infelizmente, como podemos ver na documentação da Oracle (vide sessão de links), operações executadas em materialized views (MV) não são suportadas pelos processos de atualização do banco de dados configurado como standby lógico.

Dessa forma, consultas executadas no banco de dados lógico poderão retornar valores diferentes daqueles apresentados no banco de dados principal.

Nesse artigo iremos demonstrar como manter as materialized views atualizadas no banco de dados lógico e, também, caso a materialized view utilize tabelas de outros bancos de dados, no qual o banco de relatório não tenha privilégio para acessar, como podemos mantê-las atualizadas.

Conhecendo Data Guard

O recurso Data Guard da Oracle nos permite criar cópias dos nossos bancos de dados, possibilitando utilizá-las das mais variadas formas como, por exemplo, usando as cópias apenas para configuração de ambientes de disaster recover, onde poderemos utilizar o banco de réplica como se fosse o banco principal, caso haja corrupção no banco de dados principal.

Ou ainda, permitindo consultar os dados do banco de réplicas, evitando que relatórios executados possam impactar negativamente na performance do banco de dados principal.

Quando necessário, a ação de mover o banco de dados standby para principal é muito rápida e pode ser executada utilizando apenas um comando, diminuindo drasticamente o tempo de indisponibilidade do banco de dados e permitindo que façamos as correções necessárias no banco primário, enquanto os usuários continuam a trabalhar com o banco de réplica.

O Data Guard Oracle nos permite criar três tipos de standby:

· Standby físico – é uma cópia exata do banco de dados principal. É gerenciado pelo processo MRP (Managed Recovery Process) que aplica todas as alterações de blocos registradas em redo na réplica do banco de dados;

· Standby lógico – é uma cópia do banco de dados principal. Diferente do standby físico, ele não aplica as alterações diretamente nos blocos. O processo LCR (Logical Change Records) irá ler as informações contidas nos redos gerados no banco de dados principal, analisá-las e aplicá-las no standby lógico.

Devido a essa característica, podemos configurar o standby lógico para ignorar comandos DML e DDL executados para algumas tabelas ou schemas do banco de dados principal.

Além disso, o standby lógico nos permite criar objetos que não existem no banco de dados principal como, por exemplo, criar um índice para melhorar a performance de uma consulta que é executada exclusivamente no banco de réplica.

· Standby snapshot – é uma versão do banco de dados principal. A réplica do banco é editável e permite a conversão novamente para standby físico, caso precisemos receber/aplicar alterações ocorridas no banco de dados principal.

Conceitos básicos de materialized views

Materialized views são objetos do banco de dados Oracle utilizados para armazenar dados de consultas que precisem ler uma grande quantidade de dados de diferentes tabelas/views. Elas funcionam como uma tabela do banco, populada manualmente ou via job, que permite a execução de queries complexas, lendo um único objeto de banco de dados. Além de permitir a criação de índices exclusivos, que não impactam na performance das tabelas usadas como origem de dados para as materialized views."