Alta disponibilidade no banco de dados Oracle

Mas afinal, o que realmente é a tão falada alta disponibilidade no banco de dados Oracle?

Disponibilidade é o grau de acessibilidade de uma aplicação, serviço ou função sob demanda. A disponibilidade é medida pela percepção do usuário final da aplicação. Usuários frequentemente ficam frustrados quando seus dados não estão disponíveis ou o sistema de computação não está funcionando como esperado, e eles não entendem ou se preocupam em diferenciar entre todos os componentes complexos de uma solução global para o problema. Falhas de desempenho devido ao aumento do uso esperado criam a mesma percepção que a falta de componentes críticos na arquitetura. Se um usuário não pode acessar o sistema, costuma-se dizer que o mesmo está indisponível. Geralmente, o termo “tempo de inatividade” é usado para se referir aos períodos em que o sistema não está disponível.

Os usuários que querem seus sistemas prontos para atendê-los em todas as vezes que quiserem precisam de um sistema com alta disponibilidade. Um sistema que é altamente disponível é projetado para fornecer serviços de computação ininterruptas durante os períodos essenciais, na maior parte do tempo durante o dia, e na maioria dos dias da semana ao longo do ano. Esta medida é muitas vezes apresentado como 24x7x365, ou seja, o sistema deve estar disponível nas 24 horas durante os 7 dias da semana nos 365 dias do ano. No entanto, exceções podem ser feitas para que o tempo de inatividade seja mínimo para executar determinadas operações, tais como atualização de hardware ou software do sistema.

Confiabilidade, recuperabilidade, detecção rápida de erros e operações contínuas são as características principais de uma solução de alta disponibilidade:

· Confiabilidade: ter um hardware confiável é um dos componentes de uma solução de alta disponibilidade. Softwares confiáveis, incluindo o banco de dados, servidores Web e servidores de aplicação são tão fundamentais para a implementação de uma solução de alta disponibilidade quanto um hardware confiável. Uma característica relacionada é a resiliência. Por exemplo, hardwares de baixo custo (conhecidos como blade), combinados com um software como o Oracle Real Application Clusters (Oracle RAC), podem ser usados para implementar um sistema muito confiável. A resiliência de um banco de dados permite o processamento contínuo mesmo em caso de falhas individuais de servidores;

· Recuperabilidade: pode haver muitas maneiras de se recuperar o sistema em caso de uma falha. Portanto, é importante determinar quais os tipos de falhas que podem ocorrer em seu ambiente de alta disponibilidade e como recuperar essas falhas em tempo hábil, atendendo às necessidades de negócio. Por exemplo, se uma tabela crítica é acidentalmente excluída do banco de dados, quais as medidas que devem ser tomadas para recuperá-la? A arquitetura fornece a capacidade de recuperar num tempo especificado no acordo de nível de serviço (SLA – Service Level Agreement)? Um acordo de nível de serviço (SLA – Service-Level Agreement) é uma parte de um contrato de serviço, onde um serviço é definido formalmente. Na prática, o termo é SLA é, por vezes, utilizado para se referir ao tempo de entrega contratado (do serviço ou de performance). Como exemplo, os provedores de internet comumente incluem acordos de nível de serviço dentro dos termos de seus contratos com os clientes para definir o(s) nível(s) do serviço que está sendo vendido em termos de linguagem simples. Neste caso, o SLA terá detalhes técnicos definidos no tocante a tempo médio entre falhas (MTBF – Mean Time Between Failures), tempo médio de recuperação (MTTR – Mean Time To Recover), taxa de trasferência de dados ou outro tipo de detalhe mensurável.

· Detecção rápida de erros: se um componente em sua arquitetura falhar, então a detecção rápida é essencial para se recuperar da falha inesperada. Embora seja possível de se recuperar rapidamente de uma interrupção, caso haja uma demora maior que 90 minutos para descobrir o problema, então o SLA pode não ser atendido. Monitorar a saúde do seu ambiente requer software confiável para visualizar problemas rapidamente e a capacidade de notificar o administrador de banco de dados sobre um problema;

· Operação contínua: proporcionar o acesso contínuo aos seus dados é essencial quando muito pouco ou nenhum tempo de inatividade é aceitável para executar as atividades de manutenção. Atividades, tais como mover uma tabela para outra localização no banco de dados ou até mesmo a adição de CPUs para o seu hardware deve ser transparente para o usuário final em uma arquitetura de alta disponibilidade.

Mais especificamente, uma arquitetura de alta disponibilidade deve ter as seguintes características:

· Tolerar falhas de tal forma que o processamento continua com pouca ou nenhuma interrupção;

· Ser transparente, ou tolerante, a mudanças no sistema, nos dados ou na aplicação;

· Fornecer medidas preventivas embutidas na própria arquitetura;

· Fornecer monitoramento ativo e detecção rápida de falhas;

· Fornecer recuperação rápida;

· Automatizar as operações de detecção de falhas e recuperação;

· Proteger os dados para minimizar ou prevenir a perda de dados;

· Implementar as melhores práticas operacionais para gerenciamento do ambiente;

· Alcançar as metas estabelecidas em SLAs para diminuir o máximo possível o custo total de propriedade (TCO – Total Cost of Ownership).

Custo total de propriedade (TCO) é uma estimativa financeira cujo objetivo é ajudar os consumidores e gestores de empresas a determinar os custos diretos e indiretos de um produto ou sistema. É um conceito de contabilidade de gestão que pode ser usado na contabilidade de custo total ou até mesmo economia ecológica onde se inclui os custos sociais. Para o setor de manufatura, TCO é normalmente comparado com a realização de negócios no exterior, que vai além do tempo de ciclo de produção inicial e os custos para fazer as peças. TCO inclui uma variedade de itens de custo para fazer negócios, por exemplo, envio e reenvio, e os custos de oportunidade, ao mesmo tempo em que considera os incentivos desenvolvidos para uma abordagem alternativa. Incentivos e outras variáveis incluem créditos tributários, a linguagem comum, entrega acelerada, e visitas de fornecedores orientados pelo cliente.

Importância da disponibilidade

A importância da alta disponibilidade varia entre as aplicações. Bancos de dados e a internet têm permitido a colaboração e compartilhamento de informações ao redor do mundo, estendendo o alcance dos aplicativos de banco de dados nas organizações e comunidades.

Este alcance enfatiza a importância da alta disponibilidade em soluções de gerenciamento de dados. Tanto as pequenas empresas quanto as empresas globais têm usuários em todo o mundo que precisam de acesso a dados 24 horas por dia. Sem este acesso a dados, as operações podem parar, e a receita pode estar comprometida. Os usuários atualmente exigem acordos de nível de serviço (SLA) no seu departamento de tecnologia da informação (TI) e provedores de soluções, refletindo a crescente dependência dessas soluções. Cada vez mais, a disponibilidade é medida em Reais, Dólares, Euros e Ienes, e não apenas em tempo e comodidade.

Empresas têm usado a sua infraestrutura de TI para fornecer uma vantagem competitiva, aumentar a produtividade e capacitar os usuários a tomar decisões mais informadas e mais rápidamente. No entanto, estes benefícios geram uma crescente dependência de infraestrutura. Se uma aplicação crítica se torna indisponível, o negócio pode ter problemas. O cliente pode perder receita, incorrer em penalidades, e receber má publicidade que tem um efeito duradouro sobre os clientes e sobre o preço das ações da empresa.

É importante analisar os fatores que determinam a forma como os dados são protegidos e maximizar a disponibilidade para os usuários.

Custo de downtime

A necessidade de proporcionar níveis crescentes de disponibilidade continua a acelerar à medida que as empresas reestruturam as suas soluções para obter vantagem competitiva. Na maioria das vezes, estas novas soluções contam com acesso imediato a dados críticos de negócios. Quando os dados não estão disponíveis, a operação pode deixar de funcionar. O tempo de inatividade pode levar à perda de produtividade, perda de receita, relacionamento com o cliente comprometido, má publicidade e até mesmo ações judiciais.

Nem sempre é fácil colocar um custo direto sobre o tempo de inatividade. Clientes irritados, funcionários ociosos, e má publicidade são caros, mas não são medidos diretamente em valores monetários. Por outro lado, a perda de receita e penalidades legais incorridas porque os objetivos de SLA não foram atendidos podem ser facilmente quantificadas. O custo do tempo de inatividade pode crescer rapidamente em indústrias que dependem de suas soluções para prestar serviço.

Outros fatores a considerar no custo do tempo de inatividade são:

· O período máximo tolerável de uma única interrupção não planejada: se o evento dura menos de 30 segundos pode causar um impacto muito pequeno e pode ser pouco perceptível para os usuários finais. Uma vez que o período da interrupção aumente, o efeito pode crescer exponencialmente e afetar negativamente o negócio;

· A frequência máxima de incidentes permitidas: interrupções frequentes, mesmo que de curta duração, podem igualmente interromper as operações de negócios.

Ao projetar uma solução, é importante reconhecer o verdadeiro custo do tempo de inatividade para entender como a empresa pode se beneficiar de melhorias de disponibilidade.

Causas de inatividade

Um dos desafios na concepção de uma solução de alta disponibilidade é examinar e abordar todas as possíveis causas de inatividade. É importante considerar as causas de tanto tempo de inatividade não planejada e planejada na concepção de uma infraestrutura tolerante a falhas e resiliente.

Tempo de inatividade planejada pode ser tão prejudicial para as operações quanto o tempo de inatividade não planejada, especialmente em empresas globais que suportam usuários em vários fusos horários.

As principais causas de inatividades não planejadas são:

· Falha no datacenter: uma falha no datacenter pode afetar todo o processamento neste datacenter ou um subconjunto de aplicativos suportados por ele. Alguns exemplos são:

o Falha de energia prolongada em todo o datacenter;

o Falha na rede em todo o datacenter;

o Desastre natural que faz com que datacenter fique inoperante;

o Ataque terrorista ou malicioso sobre as operações ou sobre o datacenter;

· Falha generalizada na infraestrutura de cluster (ver BOX 1): Todo o cluster que hospeda o banco de dados está indisponível. Isto inclui: falhas de nós do cluster; falha de quaisquer outros componentes que resultam no cluster estar indisponível e, consequentemente, o banco de dados estar indisponível. Alguns exemplos desta situação são:

o O último nó sobrevivente no cluster falha e há uma incapacidade de reiniciar o nó;

o A interconexão redundante do cluster falha ou o clusterware falha;

o Corrupção tão grave no banco de dados que a continuidade do servição não é possível no servidor de dados atual;

o Falha de armazenamento em disco;

· Falha do computador: A falha do computador ocorre quando o sistema que hospeda o banco de dados fica indisponível porque falhou ou não está mais acessível. Cito os seguintes exemplos:

o Falha de hardware do sistema de banco de dados;

o Falha do sistema operacional;

o Falha da instância de banco de dados;

o Falha de interface de rede;

· Falha de armazenamento: A falha de interrupção de armazenamento ocorre quando o sistema de armazenamento que suporta alguns ou todos os conteúdos do banco de dados torna-se indisponível por ter sido desligado ou não está mais acessível. Exemplos deste problema são:

o Falha de disco;

o Falha de controladora de disco;

o Falha de matriz de armazenamento;

· Corrupção de Dados: Um bloco corrompido é um bloco que tenha sido alterado de forma que esteja diferente do que o banco de dados espera encontrar. Corrupções de bloco se enquadram nas seguintes categorias: corrupções lógicas e físicas de blocos: Em um dano físico, o que também é chamado de corrupção de mídia, o banco de dados não reconhece mais o bloco, ou seja, a soma de verificação (checksum) é inválida, o bloco contém apenas zeros ou o cabeçalho e o rodapé do bloco não coincidem. Em uma corrupção lógica o conteúdo do bloco é logicamente inconsistente. Exemplos de corrupção lógica incluem a corrupção de um pedaço de linha ou entrada de índice. Corrupções de bloco também podem ser divididas em corrupção interbloco e intrablocos. Em corrupção intrabloco, o dano ocorre no próprio bloco e pode ser tanto um dano físico ou um lógico. Em uma corrupção interbloco, a corrupção ocorre entre os blocos e só pode ser uma corrupção lógica.
Uma queda por corrupção de dados ocorre quando um componente de hardware, software ou rede faz com que dados corrompidos sejam lidos ou escritos. O impacto sobre o nível de serviço de uma queda por corrupção de dados pode variar, desde uma pequena porção do banco de dados (um único bloco de dados) até uma grande parte do banco de dados (tornando praticamente inutilizável). Possíveis exemplos deste tipo de falha são:

o Falha de sistema operacional ou de driver do dispositivo de armazenamento;

o Adaptador de barramento do servidor defeituoso;

o Falha de controladora de disco;

o Erro no gerenciador de volume causando uma má leitura ou escrita em disco;

o Defeitos de software;

· Erro humano: A queda por erro humano ocorre quando as ações não intencionais ou outro tipo de ação foram executadas, fazendo com que os dados no banco de dados fiquem incorretos ou inutilizáveis. O impacto do nível de serviço de uma queda por erro humano pode variar significativamente, dependendo da quantidade e natureza crítica dos dados afetados. Exemplos deste tipo de falha são:

o Exclusão do arquivo (no nível do sistema de arquivo);

o Exclusão de objeto do banco de dados;

o Alterações de dados inadvertidamente;

o Alterações de dados maliciosamente;

· Escrita perdida: A gravação perdida é outra forma de corrupção de dados, mas é muito mais difícil de detectar e corrigir rapidamente. Uma gravação perdida ocorre quando: para uma gravação perdida, um subsistema de I/O reconhece a finalização da escrita no bloco mesmo que o I/O não tenha acontecido no dispositivo de armazenamento persistente. Em uma leitura posterior do bloco no banco de dados principal, o subsistema de I/O retorna a versão obsoleta do bloco de dados, que pode ser usada para atualizar outros blocos do banco de dados, gerando assim uma corrupção. Para uma gravação perdida, a operação de I/O foi concluída, mas foi escrito em outro lugar, e uma operação de leitura subsequente retorna o valor obsoleto. Para um sistema do Oracle RAC, uma leitura I/O a partir de um nó do cluster retorna dados obsoletos depois que a escrita de I/O foi concluída a partir de outro nó. Como exemplo pode-se citar:

o Falha de sistema operacional ou driver do dispositivo de armazenamento;

o Adaptador de barramento do servidor defeituoso;

o Falha de controladora de disco;

o Erro do gerenciador de volume;

o Outro software aplicativo;

o A falta de visibilidade da escrita dos sistemas de arquivos de rede (NFS) através de um cluster;

· Suspenção de serviço ou lentidão: ocorre quando o banco de dados ou o aplicativo é incapaz de processar transações por causa de um recurso ou contenção. Uma suspensão de serviço pode ser causada por falta de recursos do sistema. Veja alguns exemplos:

o Deadlock no banco de dados ou aplicativo. Um deadlock é uma situação em que duas ou mais ações concorrentes estão cada uma esperando que a outro chegue ao fim e, portanto, nenhuma das duas é concluida. Deadlock é um problema comum em sistemas de multiprocessamento, computação paralela e sistemas distribuídos, onde os bloqueios de hardware e software são usados para lidar com recursos compartilhados e implementar a sincronização do processo. O banco de dados detecta automaticamente deadlocks e os resolve, desfazendo todas as alterações envolvidas no deadlock, liberando um conjunto de bloqueios das linhas conflitantes para o usuário remanescente. O banco de dados retorna uma mensagem correspondente ao usuário da transação que foi desfeita. A transação desfeita é a que detectou o deadlock. Deadlocks ocorrem mais frequentemente quando as transações substituiem explicitamente o bloqueio padrão do banco de dados. Devido ao fato do banco de dados não escalonar bloqueios e não usar bloqueios de leitura para consultas, mas faz uso de bloqueios no nível de linha (ao invés de nível de página)(no caso do banco de dados Oracle, por exemplo), deadlocks ocorrem com pouca frequência.

o Processos zumbis que consomem recursos do sistema;

o Combinação de picos de aplicação com a falta de recursos do sistema ou banco de dados;

o O diretório (ou ponto de montagem) destinado aos archived redo log files está cheio. Quando é habilitado o arquivamento dos logs de redo on-line, o banco de dados Oracle copia os arquivos de redo log on-line para outro local antes de serem substituídos. Esses arquivos copiados são conhecidos como archived redo log files. Esses archived redo log files aumentam a quantidade de dados de redo que podem ser salvos e são usados para a recuperação. Archived redo log files são necessários para recuperar um backup do banco de dados a partir do momento que o backup foi feito até o momento da queda do serviço. O arquivamento pode ser ativado ou desativado para o banco de dados, mas a Oracle recomenda que seja habilitado o arquivamento. A Oracle também recomenda que seja configurado o banco de dados para gravar archived redo log files na área de recuperação rápida.

Já as principais causas de inatividades planejadas são:

· Alterações no sistema de banco de dados: mudanças planejadas no sistema ocorrem quando é necessário realizar operações de manutenção de rotina periódicas e/ou novas implantações. Estas mudanças planejadas incluem todas as alterações programadas para o ambiente operacional que ocorrem fora da estrutura organizacional de dados no banco de dados. O impacto do nível de serviço de uma mudança planejada varia significativamente dependendo da natureza e o alcance da interrupção planejada, dos esforços de teste e validação feitos antes da implementação e das tecnologias e recursos no local para minimizar o impacto. Exemplos deste tipo de alterações são:

o Adicionar ou remover processadores de um servidor SMP;

o Adicionando ou removendo nós ou de um cluster;

o Adicionar ou remover discos ao servidor;

o Alterar os parâmetros de configuração;

o Atualizar ou aplicar patch (ver BOX 2) no hardware ou software;

o Atualizar ou aplicar patch no software de banco de dados;

o Atualizar ou aplicar patch no software da aplicação;

o Migração de plataforma do sistema;

o Desativação do banco de dados;

o Alteração do sistema de 32 bits para 64 bits;

o Migrar para arquitetura de cluster;

o Migrar para um novo sistema de armazenamento;