Guia Oracle

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

Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Para efetuar o download você precisa estar logado. Clique aqui para efetuar o login
Confirmar voto
0
 (1)  (1)

Esse artigo apresenta como materialized views podem ser gerenciadas no Oracle. Através delas é possível que os dados exibidos no banco principal sejam replicados para o standby lógico.

Fique por dentro
Esse artigo irá explicar como podemos gerenciar materialized views em banco de dados Oracle, para que os dados exibidos no banco principal sejam replicados para o standby Lógico, garantindo que essas informações possam ser lidas em relatórios que são executados no banco de dados de réplica. Para isso, iremos verificar as formas de atualizar materialized views nos bancos de dados de standby lógico.

Também mostraremos como propagar o refresh da materialized views do banco primário para o standby e, em casos mais extremos, quando o banco de dados de réplica não tiver permissão para acessar o usuário do Database Link, utilizado como origem dos dados da materialized view, mas tem permissão para ler essas views.

O processo de Standby Lógico da Oracle não suporta operações de materialized views, o que pode impactar o resultado de relatórios que sejam executados no banco de dados de réplica. Seguindo os conceitos apresentados nesse artigo, iremos demonstrar como replicar essas informações nos bancos de dados de réplica.

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.

Além do u" [...]

A exibição deste artigo foi interrompida :(
Este post está disponível para assinantes MVP

 
Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Receba nossas novidades
Ficou com alguma dúvida?