Código de Disponibilidade Contínua

Seus aplicativos obtêm disponibilidade contínua quando a manutenção planejada, interrupções não planejadas e desequilíbrios de carga do banco de dados ficam ocultos do aplicativo. Uma combinação de melhores práticas de aplicativo, configuração simples e Oracle Autonomous Database garante que seus aplicativos estejam continuamente disponíveis.

A melhor abordagem para ocultar atividades de manutenção planejadas de seus aplicativos é drenar o trabalho de cada local de carga de trabalho do banco de dados de forma transparente antes da janela de manutenção desse local de carga de trabalho. Os pools de conexão e camadas intermediárias do sistema Oracle, incluindo o WebLogic Server, o Oracle Universal Connection Pool (UCP), o pool de Sessões do OCI e o Provedor Não Gerenciado do ODP.NET, têm conhecimento do mecanismo FAN (Fast Application Notification ) e, portanto, são notificados antes que os serviços de banco de dados sejam programados para serem movidos para permitir a drenagem normal do trabalho antes da manutenção. A notificação FAN aciona automaticamente o fechamento de conexões ociosas e a abertura de novas conexões no novo local de serviço, e permite um tempo configurável para que o trabalho ativo seja concluído no local de serviço prestes a ser desativado. As principais camadas intermediárias JDBC de terceiros, como IBM WebSphere, permitem o mesmo comportamento quando configuradas com o UCP. Para aplicativos baseados em JDBC que não podem usar o UCP, a Oracle fornece soluções usando o Oracle Drivers e testes de conexão.

Para ocultar interrupções não planejadas resultantes de um componente ou falha de comunicação, a Oracle fornece:

  • Notificação. O mecanismo FAN é a primeira etapa para ocultar interrupções. O FAN notifica os clientes e acaba com a espera atual da rede quando ocorre uma interrupção. Isso evita a paralisação de aplicativos por causa de longas esperas pela rede. É importante ressaltar que o FAN também chama o rebalanceamento de sessões quando os serviços estão disponíveis novamente.

  • Recuperação. Depois que o cliente é notificado, a TAC (Continuidade Transparente de Aplicativos) ou a Continuidade de Aplicativos (AC) restabelece uma conexão com um novo local de carga de trabalho (outra instância do banco de dados na configuração do RAC (Real Application Clusters) que executa o banco de dados) e repete o trabalho em andamento (não submetido a commit) quando possível. Ao repetir o trabalho em andamento no novo local, o aplicativo geralmente pode continuar em execução sem saber que houve falha.

A TAC ou a AC também é executada durante a manutenção planejada para as sessões que não são drenadas (concluem a operação atual do banco de dados) durante o intervalo de drenagem alocado.

Lista de Verificação de Configuração do Aplicativo

Você disponibiliza continuamente seu aplicativo seguindo estas diretrizes:

Dica:

Consulte o Artigo Técnico Disponibilidade Contínua para Aplicativos no ATP-Direct para conhecer as melhores práticas de implementação da disponibilidade contínua para aplicativos que usam um Autonomous Database.

Conectar Usando Serviços de Banco de Dados

Os serviços de banco de dados fornecem transparência para a infraestrutura subjacente: FAN, dados de conexão, TAC (Continuidade Transparente de Aplicativos), AC (Continuidade de Aplicativos), switchover e grupos de consumidores e muitos outros recursos e operações são previstos no uso dos serviços.

O Autonomous Database on Dedicated Exadata Infrastructure oferece vários pares de serviços de banco de dados predefinidos a serem escolhidos, conforme descrito em Nomes de Serviço de Banco de Dados Predefinidos para Autonomous Databases. Todos fornecem FAN e drenagem, e os dois pares de processamento de transações têm a TAC ativada por padrão. Uma API está disponível para alterar as definições de TAC ou AC em todos os serviços predefinidos (consulte Ativar Atributos de Serviço para Failover).

Configurar String de Conexão para Alta Disponibilidade

A Oracle recomenda a configuração da String de Conexão mostrada abaixo ao estabelecer conexão com o Oracle Autonomous Database. As strings de conexão incorporadas no arquivo tnsnames.ora fornecido pela Oracle são configuradas dessa forma. Não use a Denominação Easy Connect no cliente porque tais conexões não têm recursos de alta disponibilidade.

Use este TNS para todos os clientes Oracle versão 12.2 ou mais recente:

alias = 
(DESCRIPTION =
(CONNECT_TIMEOUT= 120)(RETRY_COUNT=20)(RETRY_DELAY=3)(TRANSPORT_CONNECT_TIMEOUT=3)
 (ADDRESS_LIST =
   (LOAD_BALANCE=on)
   (ADDRESS = (PROTOCOL = TCP)(HOST=scan-host)(PORT=1521)))
 (CONNECT_DATA=(SERVICE_NAME = service-name)))

Use o seguinte para conexões JDBC que utilizam o driver Oracle versão 12.1 ou mais antigo

alias =
(DESCRIPTION =
(CONNECT_TIMEOUT= 15)(RETRY_COUNT=20)(RETRY_DELAY=3)
(ADDRESS_LIST =
  (LOAD_BALANCE=on)
  (ADDRESS = (PROTOCOL = TCP)(HOST=scan-host)(PORT=1521)))
(CONNECT_DATA=(SERVICE_NAME = service-name)))

Usar FAN (Fast Application Notification)

O FAN fornece uma notificação imediata a um aplicativo em caso de interrupção ou retomada do serviço. Sem o FAN, os aplicativos podem travar no timeout de TCP/IP depois de falhas de hardware e rede e omitir o rebalanceamento quando os recursos são retomados. Todos os pools da Oracle e todos os servidores de aplicativos Oracle usam FAN. Os servidores de aplicativos JAVA de terceiros podem usar o UCP para ativar o FAN.

Nenhuma alteração de aplicativo é necessária para usar o FAN. Estas são apenas alterações de configuração.

Para serviço contínuo durante a manutenção planejada, use o FAN com:

  • Pools da Oracle ou
  • UCP com servidores de aplicativos JDBC de terceiros ou
  • Os drivers clientes Oracle mais recentes

Para um serviço contínuo durante interrupções não planejadas, use o FAN com:

  • Continuidade Transparente de Aplicativos ou
  • Continuidade de Aplicativos

Cobertura FAN

Os eventos de FAN são integrados com:

  • Oracle Fusion Middleware e Oracle WebLogic Server
  • Oracle Data Guard Broker
  • Oracle JDBC Universal Connection Pool ou Driver para interfaces JDBC thin e Oracle Call Interface (OCI)
  • Pool de Conexão ODP.NET para Provedores Gerenciados e Não Gerenciados
  • Oracle Tuxedo
  • SQL*Plus
  • Drivers do Oracle Database para linguagens como Python, Node.js e PHP
  • Serviços de Dados Globais
  • Servidores de aplicativos JDBC de terceiros usando o Oracle JDBC Universal Connection Pool
  • Listeners

Para ativar o FAN no Cliente

Use o alias TNS mostrado em Configurar String de Conexão para Alta Disponibilidade. Esta string de conexão é usada para configurar automaticamente a inscrição do ONS (Oracle Notification Service) no cliente para recebimento de eventos FAN ao usar um driver de cliente Oracle Database 12c ou mais recente. O ONS fornece um caminho de comunicação seguro entre a camada do banco de dados e a camada do cliente, permitindo que o cliente seja notificado sobre a disponibilidade do serviço (componentes que são interrompidos ou iniciados) e avisos sobre balanceamento de carga no runtime, para melhor posicionamento do trabalho durante a operação normal.

Dependendo do cliente, ative o FAN nas propriedades de configuração do aplicativo da seguinte forma:

  • Universal Connection Pool ou JDBC thin driver (a partir do 12.2)

    Defina a propriedade FastConnectionFailoverEnabled.

  • WebLogic Active GridLink for Oracle

    O RAC FAN e o Failover de Conexão Rápida são ativados por padrão.

  • Oracle WebLogic Server, IBM WebSphere, IBM Liberty, Apache Tomcat, Red Hat WildFly (JBoss), Aplicativos JDBC

    Use o Universal Connection Pool como uma substituição do pool de conexão.

  • Clientes ODP.Net (Provedores Gerenciados e Não Gerenciados)

    Defina "HA events = true;pooling=true" na string de conexão se estiver usando o ODP.Net 12.1 ou uma versão anterior.

  • Clientes do Oracle Call Interface (OCI) e drivers baseados no OCI

    Os clientes do Oracle Call Interface (OCI) sem definições nativas podem usar um arquivo oraacces.xml e definir events como true.

    Python, Node.js e PHP têm opções nativas. No Python e no Node.js, você pode definir um modo de eventos ao criar um pool de conexão. No PHP, edite o arquivo php.ini e adicione a entrada oci8.events=on.

  • SQL*Plus

    FAN está ativado por padrão.

Os serviços de banco de dados predefinidos oferecem conexões TCPS que usam autenticação baseada em wallet TLS. Dependendo do tipo de aplicativo (JDBC ou Oracle Call Interface), a configuração da wallet deve seguir regras específicas, conforme descrito em Configurar Clientes para FAN Incluindo Wallets Opcionais.

Usar Práticas Recomendadas para Permitir a Drenagem

A melhor prática para uso do aplicativo é fazer o check-out das conexões durante o tempo necessário e depois fazer o check-in delas novamente para o pool quando a ação atual for concluída. Isso é importante para obter um bom desempenho, para o rebalanceamento do trabalho no runtime e durante janelas de manutenção para drenagem do trabalho.

A Oracle recomenda o uso de um pool de conexão Oracle com reconhecimento de FAN para ocultar a manutenção planejada. Não há impacto para os usuários quando seu aplicativo usa um Pool Oracle com o FAN e retorna conexões com o pool entre solicitações. Você não precisa fazer alterações no aplicativo para usar o FAN. Quando um pool de conexão Oracle recebe o evento FAN para inatividade planejada, ele marca todas as conexões na instância a serem drenadas. Imediatamente, as conexões submetidas a check-in são fechadas para que não sejam reutilizadas. À medida que as conexões em uso são retornadas ao pool, elas são fechadas. Isso permite que todas as conexões sejam fechadas normalmente ao longo do tempo.

Se você estiver usando um servidor de aplicativos baseado em Java de terceiros, o método mais eficaz para obter drenagem e failover será substituir a origem de dados com pool por UCP. Muitos servidores de aplicativos oferecem suporte a essa abordagem, incluindo Oracle WebLogic Server, IBM WebSphere, IBM Liberty, Apache Tomcat, Red Hat WildFly (JBoss), Spring, Hibernate e outros. White papers da Oracle e de outros provedores, como a IBM, descrevem como usar o UCP com esses servidores de aplicativos. O uso do UCP como a origem de dados permite que recursos do UCP, como Failover de Conexão Rápida, Balanceamento de Carga de Runtime, Continuidade de Aplicativos e Continuidade Transparente de Aplicativos, sejam usados com certificação completa.

Ativar TAC (Continuidade Transparente de Aplicativos) ou AC (Continuidade de Aplicativos)

A TAC rastreia e registra de forma transparente a sessão e o estado transacional para que uma sessão de banco de dados possa ser recuperada após interrupções recuperáveis. Os dois pares de processamento de transação de serviços de banco de dados predefinidos têm a TAC ativada por padrão.

A AC é personalizável, permitindo que você escolha repetir efeitos colaterais ou adicionar callbacks complexos no failover que a TAC não permite. Use a AC se estiver usando drivers do Oracle 12c (JDBC-thin ou Oracle Call Interface) ou se quiser personalizar com efeitos colaterais ou callbacks ou se tiver um aplicativo que use estado como tabelas temporárias de duração de sessão e não faça limpeza entre solicitações.

Etapas para Usar a Continuidade Transparente de Aplicativos

  • Se você precisar ativar a Continuidade Transparente de Aplicativos no serviço de banco de dados que está usando, consulte Ativar Atributos de Serviço para Failover.

  • Use um dos clientes compatíveis a seguir.

    A Oracle recomenda que você use os drivers mais recentes do cliente. Os drivers do cliente Oracle Database 19c e mais recentes são totalmente compatíveis com a TAC.

    • Oracle JDBC Replay Driver 18c ou mais recente. Este é um recurso do driver JDBC fornecido no Oracle Database 18c para Continuidade de Aplicativos.
    • Oracle Universal Connection Pool (UCP) 18c ou mais recente com o Oracle JDBC Replay Driver 18c ou mais recente.
    • Oracle WebLogic Server Active GridLink ou servidores de aplicativos JDBC de terceiros usando o UCP com o Oracle JDBC Replay Driver 18c ou mais recente.
    • Pools de conexão Java ou aplicativos Java independentes usando o Oracle JDBC Replay Driver 18c ou mais recente.
    • Oracle Call Interface Session Pool 19c ou mais recente.
    • SQL*Plus 19c (19.3) ou mais recente
    • ODP.NET em pool, Driver Não Gerenciado 18c ou mais recente ("Pooling=true" padrão na versão 12.2 e mais recente).
    • Aplicativos baseados no Oracle Call Interface que usam o driver OCI 19c ou mais recente.
  • Retorne Conexões ao Pool de Conexão.

    Você não precisa fazer nenhuma alteração em seu aplicativo para identificar limites de solicitação se o aplicativo usar conexões:

    • dos pools de conexão Oracle ou
    • do Oracle JDBC Replay Driver 18c ou mais recente ou
    • dos aplicativos baseados no Oracle Call Interface que usam o 19c ou mais recente

    Ao usar pools de conexão, o aplicativo deve retornar a conexão com o pool após a conclusão de cada solicitação. A Oracle recomenda que um aplicativo faça check-out de uma conexão apenas pelo tempo necessário. Manter uma conexão quando ela não estiver em uso não é uma boa prática. A Continuidade Transparente de Aplicativos com os drivers listados também detecta onde os limites podem ser adicionados e cria seus próprios limites.

  • Use FAILOVER_RESTORE

    A ativação da Continuidade Transparente de Aplicativos restaura automaticamente os estados de sessão predefinidos. Se você achar que precisa de estados de sessão predefinidos além do conjunto padrão, poderá registrar um callback ou um rótulo do UCP para restaurar esses estados. Se você achar que precisa de estados de sessão complexos, como tabelas temporárias ou SYS_CONTEXT, restaurados, use a Continuidade de Aplicativos que oferece essa flexibilidade.

  • Ativar Uso Mutável no Aplicativo

    Funções mutáveis são funções que podem retornar um novo valor cada vez que são executadas. O suporte para manter os resultados originais é fornecido para SYSDATE, SYSTIMESTAMP, SYS_GUID e sequence.NEXTVAL. A Continuidade de Aplicativos 19c e mais recentes usa o privilégio KEEP para manter automaticamente os mutáveis para SQL. Se seu aplicativo usa ou é sensível a funções mutáveis, um DBA deverá emitir o privilégio GRANT KEEP. Quando o privilégio KEEP é concedido, a repetição aplica o resultado original da função na repetição. Por exemplo:

    SQL> GRANT [KEEP DATE TIME | KEEP SYSGUID] … TO USER
    SQL> GRANT KEEP SEQUENCE mySequence TO myUser ON sequence.object
  • Os Efeitos Colaterais Estão Desativados

    Um efeito colateral é uma ação externa, como enviar e-mail, transferir arquivos ou usar TCP. A Continuidade Transparente de Aplicativos detecta efeitos colaterais e não os repete. Se você quiser que os efeitos colaterais sejam repetidos, use a Continuidade de Aplicativos que permite essa flexibilidade extra.

Etapas para Usar a Continuidade de Aplicativos

  • Se você precisar ativar a Continuidade de Aplicativos no serviço de banco de dados que está usando, consulte Ativar Atributos de Serviço para Failover.

  • Use um dos clientes compatíveis a seguir.

    • Oracle JDBC Replay Driver 12c ou mais recente. Este é um recurso do driver JDBC fornecido no Oracle Database 12c para Continuidade de Aplicativos.
    • Oracle Universal Connection Pool (UCP) 12c ou mais recente com o Oracle JDBC Replay Driver 12c ou mais recente.
    • Oracle WebLogic Server Active GridLink e servidores de aplicativos JDBC de terceiros que usam o UCP com o Oracle JDBC Replay Driver 12c ou mais recente.
    • Pools de conexão Java ou aplicativos Java independentes com o Oracle JDBC Replay Driver 12c ou posterior com Limites de Solicitação ou Origem de Dados com Pool.
    • Aplicativos e drivers de idioma usando o Pool de Sessões Oracle Call Interface 12c Versão 2 ou posterior.
    • SQL*Plus 19.3 ou mais recente.
    • ODP.NET em pool, Driver Não Gerenciado 12c Versão 2 ou mais recente ("Pooling=true";"Application Continuity=true" padrão na versão 12.2 e mais recente)
  • Retorne Conexões ao Pool de Conexão.

    Você não precisa fazer alterações no seu aplicativo para identificar limites de solicitação se o aplicativo estiver usando um pool de conexão Oracle ou um pool JDBC de terceiros que suporte limites de solicitação. Dentre as melhores práticas estão o uso de um pool Oracle e o retorno das conexões a esse pool entre solicitações. A Oracle recomenda que um aplicativo faça check-out de uma conexão apenas pelo tempo necessário. Manter uma conexão quando não estiver em uso não é uma boa prática e evitará a manutenção planejada transparente.

  • Use FAILOVER_RESTORE

    A maioria dos estados comuns é restaurada automaticamente com FAILOVER_RESTORE=LEVEL1. Se o seu aplicativo predefinir estados de sessão além do conjunto padrão, você deverá registrar um callback ou um rótulo do UCP para restaurar esses estados. Defina FAILOVER_RESTORE=LEVEL1 no serviço e use:

    • Callback de Inicialização de Conexão para Java ou o Callback TAF (mais antigo) para Oracle Call Interface ou
    • Rotulagem de Conexão do Universal Connection Pool ou WebLogic Server
  • Ativar Uso Mutável no Aplicativo

    Funções mutáveis são funções que podem retornar um novo valor cada vez que são executadas. O suporte para manter os resultados originais é fornecido para SYSDATE, SYSTIMESTAMP, SYS_GUID e sequence.NEXTVAL. A Continuidade de Aplicativos 19c e mais recentes usa o privilégio KEEP para manter automaticamente os mutáveis para SQL, portanto, nenhuma ação é necessária. Se você precisar de mutáveis para PL/SQL, um DBA deverá emitir o privilégio GRANT KEEP. Quando o privilégio KEEP é concedido, a repetição aplica o resultado original da função na repetição. Por exemplo:

    SQL> GRANT [KEEP DATE TIME | KEEP SYSGUID] … TO USER
    SQL> GRANT KEEP SEQUENCE mySequence TO myUser ON sequence.object
  • Decida se Deseja Repetir Efeitos Colaterais

    Um efeito colateral é uma ação externa, como enviar e-mail, transferir arquivos ou usar TCP. Com a Continuidade de Aplicativos, os efeitos colaterais são repetidos, a menos que o aplicativo especifique o contrário. Se uma solicitação tiver uma ação externa que não deve ser repetida, essa solicitação poderá usar uma conexão que não tenha a Continuidade de Aplicativos ativada ou a repetição poderá ser desativada para essa solicitação usando a API disableReplay() para Java ou OCIRequestDisableReplay() para o Oracle Call Interface. Se você não quiser repetir todos os efeitos colaterais, use a Continuidade Transparente de Aplicativos.