RAC, Data Guard e Stream são três ferramentas no sistema de alta disponibilidade da Oracle. Cada ferramenta pode ser usada de forma independente ou em combinação. Elas têm focos diferentes e são aplicáveis em cenários distintos.
O RAC destaca-se ao lidar com pontos únicos de falha e balanceamento de carga. Portanto, o RAC é frequentemente utilizado em sistemas críticos 24/7. No entanto, na solução RAC, os dados existem em apenas uma cópia. Embora falhas de armazenamento possam ser evitadas por meio de mecanismos como RAID, os próprios dados não têm redundância, tornando-os suscetíveis a pontos únicos de falha.
O Data Guard fornece proteção de dados por meio de dados redundantes. Ao utilizar mecanismos de sincronização de logs, o Data Guard garante a sincronização entre os dados redundantes e os dados primários. Essa sincronização pode ser realizada de várias formas, como em tempo real, com atraso, síncrona ou assíncrona. O Data Guard é frequentemente usado em soluções de recuperação de desastres remotos e alta disponibilidade para pequenas empresas. Embora ele permita consultas somente leitura na máquina de standby para aliviar a pressão de desempenho no banco de dados principal, o Data Guard não é principalmente destinado como uma solução de desempenho.
Streams, construídos sobre a Oracle Advanced Queue, permite a sincronização de dados e oferece configurações flexíveis em diversos níveis. Como a Oracle fornece amplo suporte para desenvolvimento, incluindo APIs ricas, Streams são mais adequados para compartilhamento de dados no nível de aplicação.
O que é o Data Guard?
Em um ambiente do Data Guard, existem pelo menos dois bancos de dados: um em estado aberto fornecendo serviços externamente, conhecido como o Banco de Dados Principal, e o outro em estado de recuperação, conhecido como o Banco de Dados de Standby. Durante a execução, o Banco de Dados Principal atende os clientes e as operações dos usuários são registradas em logs online e arquivados, que são transmitidos posteriormente para o Banco de Dados de Standby pela rede. Esses logs são reproduzidos no Banco de Dados de Standby para alcançar a sincronização de dados entre os dois.
O Oracle Data Guard otimiza ainda mais esse processo, automatizando e simplificando as tarefas de transmissão de logs e recuperação, ao mesmo tempo em que fornece uma série de parâmetros e comandos para facilitar o trabalho dos administradores de banco de dados (DBAs).
Se houver fatores antecipados que exigem que o Banco de Dados Primário seja desligado, como atualizações de software ou hardware, o Banco de Dados de Espera pode ser alternado para se tornar o Banco de Dados Primário e continuar atendendo os clientes. Isso minimiza o tempo de inatividade do serviço e garante a integridade dos dados. Em caso de problemas inesperados que deixem o Banco de Dados Primário indisponível, o Banco de Dados de Espera pode ser forçado a se tornar o Banco de Dados Primário e continuar atendendo os clientes. O nível de perda de dados nessas situações depende do nível de proteção de dados configurado. Portanto, os bancos de dados Primário e de Espera são papéis conceituais que não estão fixos em bancos de dados específicos.
Arquitetura Data Guard
A arquitetura Data Guard pode ser dividida em três partes funcionais:
1) Reenvio de Redo:
Durante a execução do Banco de Dados Principal, os logs de redo são gerados continuamente e precisam ser enviados para o Banco de Dados de standby. Essa ação de envio pode ser realizada pelos processos LGWR ou ARCH do Banco de Dados Principal. Destinos diferentes para arquivamento podem usar métodos diferentes, mas para um destino específico, só pode ser selecionado um método. A escolha do processo tem um impacto significativo nas capacidades de proteção de dados e na disponibilidade do sistema.
2) Recebimento Novamente:
O processo RFS (Remote File Server) no Banco de Dados em Estado de Espera recebe os logs e os escreve nos arquivos Standby Redo Log ou nos arquivos de Logs Arquivados, dependendo do método de transporte de logs do Banco de Dados Primário e da localização do Banco de Dados em Estado de Espera. Se os logs forem escritos nos arquivos Standby Redo Log, então, quando uma troca de log ocorrer no Banco de Dados Primário, isso acionará uma troca de log no Standby Redo Log do Banco de Dados em Estado de Espera e arquivará esse Standby Redo Log. Se os logs forem escritos nos Logs Arquivados, essa ação pode ser considerada ela própria uma operação de arquivamento.
3) Reaplicação:
O serviço de reaplicação é responsável por reproduzir os logs do Banco de Dados Primário no Banco de Dados em standby, assim alcançando a sincronização de dados entre os dois bancos de dados.
Dependendo de como o Banco de Dados em Estado de Prontidão reproduz os logs, existem dois tipos: Banco de Dados Físico em Prontidão e Banco de Dados Lógico em Prontidão.
Com base em quando ocorre a Aplicação Redo, existem também dois tipos:
a) Aplicação em Tempo Real: Este método requer o uso do Standby Redo Log. Sempre que um log é gravado no Standby Redo Log, ele dispara a recuperação. O benefício deste método é que ele reduz o tempo necessário para a troca de banco de dados, pois os logs restantes já foram recuperados em tempo real.
b) Aplicar no Arquivamento: Este método aplica os logs quando uma troca de log ocorre no Banco de Dados Primário e dispara o arquivamento no Banco de Dados Secundário. A recuperação é iniciada após o processo de arquivamento ser concluído. Este também é o modo de recuperação padrão.
Standby Físico vs. Standby Lógico
Existem dois tipos de Bancos de Dados Standby: Standby Físico e Standby Lógico.
1. Banco de Dados Standby Físico:
O banco de dados Standby Físico é igual ao banco de dados Primário. O Data Guard mantém o banco de dados Standby Físico por meio da aplicação de REDO. Geralmente, quando o Standby Físico não está aplicando REDO, ele pode ser aberto no modo SOMENTE LEITURA. Se uma Área de Flashback for especificada no banco de dados, ele pode até ser temporariamente alterado para o modo LEITURA/ESCRITA para operações. Após concluir as operações necessárias, o banco de dados pode ser restaurado ao seu estado anterior ao modo LEITURA/ESCRITA usando o recurso Flashback Database, permitindo que a aplicação dos dados REDO do banco de dados Primário continue.
Nota: A funcionalidade da aplicação do Physical Standby foi aprimorada no Oracle 11g. Nesta versão, o Physical Standby pode continuar aplicando dados REDO enquanto estiver no modo OPEN READ ONLY. Isso melhora muito a usabilidade dos bancos de dados Physical Standby.
Recursos do Standby Físico:
1) Recuperação de desastres e alta disponibilidade: O Physical Standby fornece uma solução robusta e eficiente para recuperação de desastres e alta disponibilidade. Ele simplifica o gerenciamento de failover/switchover e reduz o tempo de inatividade planejado ou não planejado.
2) Proteção de dados: Com um banco de dados Standby Físico, o Data Guard garante que a perda de dados é minimizada, mesmo diante de desastres imprevistos.
3) Reduzir a carga de trabalho do banco de dados Primário: Ao transferir algumas tarefas, como backups e consultas somente leitura, para o banco de dados Físico de Reparo, os recursos de CPU e E/S no banco de dados Primário podem ser preservados.
4) Melhoria no desempenho: O mecanismo de aplicação de REDO usado em bancos de dados Physical Standby opera no nível mais baixo da recuperação, contornando a execução do código SQL. Isso resulta na maior eficiência e desempenho.
2. Standby Lógico:
Um banco de dados Standby Lógico também é criado com base no banco de dados Primário (ou em seus backups ou réplicas, como o Standby Físico). Portanto, inicialmente, ele é semelhante a um banco de dados Standby Físico no início. No entanto, já que um Standby Lógico aplica dados REDO por meio da execução de SQL, sua estrutura de arquivos física e até mesmo a estrutura lógica dos dados podem ser diferentes do banco de dados Primário.
Ao contrário do Physical Standby, um Logical Standby normalmente é aberto no modo READ WRITE, permitindo que os usuários acessem whenever desejarem. Em outras palavras, a execução de SQL ocorre enquanto o Logical Standby está em estado OPEN. Isso tem vantagens e desvantagens. Devido à natureza da execução de SQL, existem limitações operacionais em determinados tipos de dados e algumas instruções DDL/DML em um Logical Standby. Você pode verificar os tipos de dados não suportados na visão DBA_LOGSTDBY_UNSUPPORTED. Se tais tipos de dados forem usados, não é possível garantir a consistência completa no banco de dados.
A abertura no modo READ WRITE de um Standby Lógico torna-o adequado para uso como sistema de relatórios, aliviando a carga de trabalho do sistema.
Recursos do Logical Standby:
Além das características mencionadas anteriormente para o Physical Standby, como recuperação de desastres, alta disponibilidade e proteção de dados, o Logical Standby possui as seguintes características:
1) Utilização eficiente dos recursos de hardware no servidor de backup: Um banco de dados Logical Standby pode ser usado para criar índices adicionais, visualizações materializadas e atender necessidades específicas do negócio. Também é possível criar novos esquemas (que não existem no banco de dados Principal) e executar operações DDL ou DML que não são apropriadas no banco de dados Principal.
2) Reduzir a carga de trabalho do banco de dados Primário: Ao manter o banco de dados Logical Standby aberto enquanto permanece sincronizado com o banco de dados Primário, ele pode atender tanto às operações de proteção de dados quanto às de relatórios. Isso alivia o banco de dados Primário de tarefas de relatórios e consultas, economizando recursos valiosos de CPU e E/S.
3) Atualizações suaves: Logical Standby pode ser usado para operações como atualizações entre versões e aplicação de patches no banco de dados.
Modos de Proteção de Dados
O Data Guard permite três modos de proteção de dados: Proteção Máxima, Disponibilidade Máxima e Desempenho Máximo.
1. Proteção Máxima:
Este modo garante nenhuma perda de dados. Para alcançar isso, todas as transações devem não apenas ser escritas nos logs de Redo Local antes do commit, mas também ser escritas simultaneamente nos logs de Redo Standby no banco de dados Standby. Os dados REDO precisam estar acessíveis em pelo menos um banco de dados Standby (se houver múltiplos) antes de poderem ser confirmados no banco de dados Primário. Em caso de o banco de dados Standby ficar indisponível devido a uma falha (por exemplo, interrupção de rede), o banco de dados Primário será desligado para evitar perda de dados.
Habilitar este modo requer que o Banco de Dados em Standby seja configurado com Logs de Redo em Standby, e que o Banco de Dados Primário use o modo LGWR, SYNC, AFFIRM para arquivamento no Banco de Dados em Standby.
2. Disponibilidade Máxima:
Este modo fornece o mais alto nível de estratégia de proteção de dados sem afetar a disponibilidade do banco de dados Primário. Ele segue uma implementação semelhante ao Modo de Proteção Máxima, onde as transações locais devem ser gravadas em pelo menos um Banco de Dados Reserva nos Logs de Redo da Reserva antes do commit. No entanto, a diferença é que se ocorrer uma falha que torne o banco de dados Reserva inacessível, o banco de dados Primário automaticamente mudará para o modo de Desempenho Máximo em vez de desligar. Assim que o banco de dados Reserva se recuperar, o banco de dados Primário automaticamente voltará ao modo de Disponibilidade Máxima.
Embora este modo tenha como objetivo minimizar a perda de dados, ele não pode garantir consistência absoluta de dados. Assim como o Maximum Protection, este modo exige que o Banco de Dados de Prontidão seja configurado com Logs de Redo de Prontidão, e que o Banco de Dados Primário use o modo LGWR, SYNC, AFFIRM para arquivamento no Banco de Dados de Prontidão.
3. Desempenho Máximo:
Este modo fornece o mais alto nível de estratégia de proteção de dados sem impactar o desempenho do banco de dados Primário. As transações podem ser confirmadas a qualquer momento, e os dados REDO do banco de dados Primário atual precisam ser escritos em pelo menos um banco de dados Reserva, embora isso possa ser feito de forma assíncrona. Sob condições ideais de rede, este modo pode fornecer proteção de dados semelhante ao Modo de Disponibilidade Máxima, enquanto tem apenas um impacto mínimo no desempenho do banco de dados Primário. Este é o modo de proteção padrão ao criar um banco de dados Reserva. Ele pode ser alcançado usando os processos LGWR ASYNC ou ARCH, e logs REDO Reserva não são necessários para o banco de dados Reserva.
Etapas para Modificar o Modo de Proteção de Dados:
1. Desligue o banco de dados e reinicie-o no estado de Montagem. Se for uma configuração RAC, desligue todas as instâncias e inicie apenas uma instância no estado de Montagem.
2. Modifique o modo usando a seguinte sintaxe:
ALTERAR BANCO DE DADOS DEFINIR BANCO DE DADOS EM MODO DE ESPERA PARA MAXIMIZAR {PROTEÇÃO | DISPONIBILIDADE | DESEMPENHO};
Por exemplo: SQL>ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE PROTECTION;
3. Abra o banco de dados: ALTER DATABASE OPEN;
4. Confirme o modo de proteção de dados modificado:
SQL>select protection_mode,protection_level from v$database;
Serviços de Aplicação de Log
Data Guard garante a consistência entre o banco de dados Primário e os bancos de dados em Standby aplicando REDO. Por trás dos bastidores, apoiando silenciosamente esse processo, estão os renomados Serviços de Aplicação de Log. Existem dois tipos de Serviços de Aplicação de Log:
1. Aplicação de REDO: Exclusivo para bancos de dados Standby físicos, ele os mantém sincronizados com o banco de dados Primário por meio da recuperação de mídia.
2. SQL Apply: Exclusivo para bancos de dados Standby lógicos, sua funcionalidade principal envolve analisar instruções SQL por meio do LogMiner e executá-las no lado Standby.
Portanto, ao aplicar dados REDO, o banco de dados Standby físico deve estar em um estado MOUNT, enquanto o banco de dados Standby lógico está aberto no modo READ WRITE para a aplicação dos dados REDO. No entanto, os objetos sendo mantidos são definidos como somente leitura por padrão e não podem ser modificados diretamente no lado do Standby lógico.
Proteja o banco de dados Oracle com uma solução profissional
O Oracle Data Guard é uma solução robusta para alta disponibilidade, proteção de dados e recuperação de desastres. É uma ferramenta crucial para empresas que não podem se dar ao luxo de ter tempos de inatividade significativos ou perda de dados. No entanto, para proteger ainda mais seu ambiente de banco de dados, é recomendável fazer backup do seu banco de dados Oracle com uma solução profissional de backup e recuperação de desastres.
Vinchin Backup & Recovery oferece funcionalidade poderosa para proteger seus bancos de dados em máquinas virtuais e servidores físicos, sendo bastante automático, flexível e eficiente. Ele fornece proteção para vários tipos de banco de dados de Oracle DB, MySQL, SQL Server, Postgres Pro e MariaDB, com suporte para compressão de banco de dados, gerenciamento centralizado de tarefas, estratégias inteligentes de backup, backup de banco de dados quente e suporte avançado ao SQL Server/Oracle. Além disso, também oferece suporte ao recurso poderoso de proteção contra ransomware e migração V2V em mais de 10 plataformas virtuais.
O Vinchin Backup & Recovery foi selecionado por milhares de empresas e você também pode começar a usar este poderoso sistema com uma versão de trial de 60 dias com todas as funcionalidades! Além disso, entre em contato conosco e relate suas necessidades, e então você receberá uma solução de acordo com o seu ambiente de TI.
Conclusão
O Oracle Data Guard é um componente crucial para qualquer implantação de banco de dados Oracle em nível empresarial, oferecendo uma solução abrangente para recuperação de desastres, alta disponibilidade, proteção de dados e balanceamento de carga de trabalho. Sua arquitetura flexível e vários modos de operação tornam-no adaptável a uma ampla gama de necessidades comerciais e requisitos operacionais.
Você pode escolher o Vinchin Backup & Recovery para fazer backup e recuperar seus bancos de dados Oracle de forma fácil. Não perca o teste gratuito!
