Oracle Database 11g: "ClientFailover" em "Standby Databases"

Uma cordial saudação aos estimados Oracle tecnólogos. Através deste presente artigo, temos a oportunidade de abordar um tema de grande importância, o conceito do “ClientFailover” em banco de dados “Standby”

Introdução

Nas repetidas ocasiões em que precisamosanalisar implementações de infraestruturanos clientes, uma das primeiras coisas que fazemos é verificar se as boas práticas estãosendo utilizadas e se elas estão realmente aplicadas.

No momento de fazer um "Standby Database". Sempre fazemos a mesma pergunta..: Qual é o procedimento ou método utilizado para gerenciar as conexões com as aplicações,no momento da realização do “Switchover“ ou de um “Failover”?

As respostas são diferentes, porém a mais típico em muitos casos:

Como quase nunca realizamos “Switchover” muito menos “Failover” é raro a necessidade de redirecionar as conexões das aplicações, portanto dado o tempo para executar essa operação, nós nos dirigimos ao servidor de aplicação e ali editamos manualmente as entradas do TNSNAMES, que direciona a nossa base de dados produção e mudamos posteriormente as conexões para o servidor “Standby” ... que estará operando na função do banco primário.

No geral, muitos clientes aplicam métodos manuais para redirecionar suas aplicações para servidores nos banco de dados "Standby", uma vez efetuada a operação do tipo "Switchover" ou "Failover".

Antes de ir mais longe neste artigo, uma pergunta que deveria ser feita por todos os DBAS na hora da implementação das soluções “Standby Databases”/”Data Guard”. Os produtos Oracles desfrutam de um elevado nível técnico, e ainda mais quando eles têm várias versões de desenvolvimento como o tema relacionado ao “Standby Databases”/”Data Guard”. A questão é a seguinte: se as soluções acima tem a possibilidade de realizar operações de Switchover/Failover, a Oracle Corp, iria deixar de lado o desenvolvimento ea disponibilidade para que as aplicações pudessem estar em alta disponibilidade como mencionado anteriormente?

A resposta para a pergunta é .. Se .. "A Oracle Corp" possui uma solução para este modelo, o mesmo é chamado de "ClientFailover" para as conexões de aplicativos. O conceito que se refere o "ClientFailover" não é baseado apenas no contexto do "Data Guard". Para obter mais informações sobre ele, temos aqui abaixo alguns links que podem cobrir profundamente todas as informações sobre o tema:

ClientFailover Best Practices for HighlyAvailable Oracle Databases: Oracle Database 11g Release 2

a/tech/docs/technical-resources/maa-wp-11gr2-client-failover.pdf

How To Configure ClientFailover For Dataguard Connections Using Database Services (Doc ID 1429223.1)

O objetivo deste artigo é apresentar uma breve e eficaz técnica para uma dos principais métodos de implementação "ClientFailover" na solução do "Data Guard". Através dos links fornecidos, você pode desfrutar do tempo como um contexto geral.

Vamos começar ...

A figura abaixo mostra uma típica configuração de uma solução "Data Guard"

As primeiras mudanças serão aplicadas no arquivo "tnsnames.ora" & "sqlnet.ora" tanto para os servidores como para os clientes. Na figura podemos ver um servidor com IP: 192.168.56.146 conceitualmente que serve como um servidor primário eo segundo endereço IP: 192.168.56.136 como um servidor "Standby". Ao verificar as entradas do TNS, poderá encontrar dois servidores listados. No arquivo "sqlnet.ora", estará incluído o parâmetro "SQLNET.INBOUND_CONNECT_TIMEOUT"

Para maiores informações deste parâmetro“SQLNET.INBOUND_CONNECT_TIMEOUT”, colocamos aqui a referência e a descrição textual da documentação oficial da Oracle.

http://docs.oracle.com/cd/B28359_01/network.111/b28317/sqlnet.htm#CIHCCCHD

O principal objetivo do artigo eda tecnologia que estamos discutindo aqui, é o de proporcionar um ambiente em que é possível o cliente se conectarai banco de dados principal independentemente se este está em qualquer um dos servidores, sem modificar nenhum arquivo,quando uma transição é causada por uma "Switchover" ou "Failover".

Na figura abaixo, temos como exemplo a execução de uma operação de "Failover". Internamente no banco de dados de produção os dados são replicados via "Standby", temos um serviço para este caso,que é chamado de "ADMAPP". O mesmo será iniciado "started" somente no banco de dados principal, e no banco de dados "Standby", ele estará interrompido. O controle desse serviço, é realizado através de um disparador de eventos (trigger) do tipo "Startup on Database". Como você pode visualizar o código é bastante simples, caso a regra queexecuta o banco de dados no momento for do tipo “Primary”, proceder para iniciar o serviço, senão permanecer o serviço detido, como é a condição padrão no início da banco de dados.

Vamos seguir com o cenário em que já foi realizada operação "Swithover" ou "Failover". Como resultado da transformação do banco primário em “Standby Database” ou vice-versa para o banco original “Standby Database”, que no momento desempenha a regra como banco de dados primário.

No caso descrito, os clientes podem se conectar sem qualquer problema sob esta nova configuração porque o serviço "ADMAPP" é iniciado no banco de dados principal que está trabalhando no servidor (192.168.56.136). Analisando Configuração do tnsnames, observe que ele suporta a conexão descrita.

Portanto, desta forma simples, podemos estabelecer o "ClientFailover" para os banco de dados "Standby". É mostrada aqui o conceito principal. Informações adicionais sobre o que aconteceria com o funcionamento do "Observer" deve ser definido, aplicando o método TAF.. toda essa cobertura será na segunda parte.

Para concluir este artigo, mostraremos um exemplo de "tnsentry" para apoiar o modelo descrito para o ambiente RAC. Como você pode ver, para esse caso seria a solução típica que forma o primário (produção de banco de dados RAC) e do lado "Standby" configurado para este caso,como um servidor baseado como "instância única".

Descrição da Figura:

* “LOAD_BALANCE” & “FAILOVER” para os 2 itens da lista ( Configuração RAC & “Single Instance” )
* Como é normal e habitual o conceito de “LOAD_BALANCE” para a configuração interna nas soluções RAC.

Caros leitores, chegamos ao final dessa matéria, esperando que este artigo seja útil. Nos despedimos e até a próxima.

Saudações!

Joel Pérez é um DBA (Oracle ACE Director, Maximum Availability OCM, OCM Cloud Admin. & OCM12c/11g) Especialista com mais de 16 anos de experiência real no mundo da tecnologia Oracle, especializada na concepção e implementação de soluções: Nuvem, alta disponibilidade, recuperação de desastres, Upgrades, replicação e toda a área relacionada com bancos de dados Oracle. Joel serve como "Chief Technologist & MAA, TEM Architect" para www.Enmotech.com Yunhe ENMO (Beijing) Technology Co. Ltd. Beijing, China. OCM Perfil Joel Perez: http://education.oracle.com/education/otn/JoelPerez.htm

Mahir M. Quluzade é um DBA Sênior com mais de 10 anos de experiência em banco de dados Oracle com foco principal na alta disponibilidade e soluções de recuperação de desastres (RAC, Data Guard, RMAN, ...). Mahir está atualmente trabalhando no Banco Central da República do Azerbaijão. Ele é um DBA OCP. Mahir é membro fundador do Azerbaijão a Oracle User Group (AZEROUG); também é um blogger. Siga Mahir em seu bloghttp://www.mahir-quluzade.com

Flávio Soares é um Oracle DBA Sênior, Exadata DMA, Troubleshooter e Consultor Oracle, certificado em OCP/OCE RAC. Especialista em Exadata, alta disponibilidade e replicação de dados com soluções Oracle. Flávio disponibiliza frequentes informações para a comunidade Oracle através do seu blog http://flaviosoares.com/pt

Este artigo foi revisto pela equipe de produtos Oracle e está em conformidade com as normas e práticas para o uso de produtos Oracle.