Documentação do Oracle Cloud Infrastructure

Configuração do Cliente para Disponibilidade Contínua no Autonomous Database

Não é necessário reiniciar aplicativos para atividades de manutenção planejadas quando você ativa a Continuidade de Aplicativos e segue as melhores práticas de codificação.

Tópico principal: Usar a Continuidade de Aplicativos no Autonomous Database

Estabelecer Conexão Usando Serviços de Banco de Dados com o Application Continuity Ativado

Os serviços de banco de dados Oracle fornecem transparência para a infraestrutura subjacente do Autonomous Database.

As operações de alta disponibilidade e continuidade de aplicativos se baseiam no uso de serviços de conexão do Autonomous Database. Para obter a continuidade do aplicativo, use um serviço de banco de dados quando se conectar ao seu banco de dados.

Os nomes dos serviços de banco de dados predefinidos no Autonomous Database são diferentes, dependendo da sua carga de trabalho, conforme descrito em Nomes de Serviço de Banco de Dados para Autonomous Database.

Usar Práticas Recomendadas que Suportam a Drenagem

No Autonomous Database, nunca é necessário reiniciar os servidores de aplicativos quando a manutenção planejada segue as melhores práticas.

Para manutenção planejada, a abordagem recomendada é fornecer tempo para a conclusão do trabalho atual antes do início da manutenção. No Autonomous Database, isso acontece automaticamente e o trabalho é drenado antes de iniciar as atividades de manutenção quando você segue estas diretrizes:

  • FAN com Pools de Conexões Oracle ou Drivers Oracle
  • Testes de conexão

Use a drenagem em combinação com a solução de failover escolhida para as solicitações que não são concluídas dentro do tempo alocado para drenagem. Sua solução de failover tentará recuperar sessões que não foram drenadas no tempo alocado.

Retornar Conexões ao Pool de Conexões

O aplicativo deve retornar a conexão ao pool de conexões em cada solicitação. É uma prática recomendada que um aplicativo faça check-outs de uma conexão apenas pelo tempo que ela precisar. Não é possível manter uma conexão em vez de retorná-la ao pool. Um aplicativo deve, portanto, fazer o check-out de uma conexão e, em seguida, fazer o check-in dessa conexão imediatamente, o trabalho é concluído. As conexões ficam disponíveis para uso posterior por outros threads ou seu thread quando necessário novamente. Retornar conexões a um pool de conexões é uma recomendação geral, independentemente de você usar FAN para drenar ou testes de conexão para drenar.

Usar um Pool de Conexões Oracle

Usando um pool de conexões FAN, o pool de conexões Oracle é a solução recomendada para ocultar a manutenção planejada. À medida que a manutenção progride e é concluída, as sessões são movidas e rebalanceadas. 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. Os Pools Oracle Suportados incluem UCP, WebLogic GridLink, Tuxedo, Pool de Sessões do OCI e provedores Gerenciados e Não Gerenciados ODP.NET. Nenhuma alteração de aplicativo é necessária para usar o FAN além de garantir que suas conexões sejam retornadas ao pool entre solicitações.

Usar UCP com um Pool de Conexões de Terceiros

Se você estiver usando um servidor do aplicativo baseado em Java de terceiros, o método mais eficaz para obter drenagem e failover é substituir a origem de dados em pool pelo UCP. Essa abordagem é suportada por muitos servidores de aplicativos, incluindo Oracle WebLogic Server, IBM WebSphere, IBM Liberty, Apache Tomcat, Red Hat WildFly (JBoss), Spring e Hibernate, entre outros.

Usar Testes de Conexão

Se você não puder usar um Pool Oracle com FAN, o Autonomous Database ou os drivers de cliente fornecidos drenarão a sessão. Quando os serviços são realocados ou interrompidos durante a manutenção ou há um switchover para um site stand-by usando o Autonomous Data Guard, os drivers do cliente Oracle Database e Oracle procuram locais seguros para liberar conexões de acordo com as seguintes regras:

  • Testes de conexão padrão para validade de conexão no empréstimo ou devolução de um pool de conexões
  • Testes SQL personalizados para validade de conexão
  • Os limites da solicitação estão em vigor e a solicitação atual foi encerrada

Usar Testes de Conexão com o Autonomous Database

Você pode adicionar, excluir, ativar ou desativar testes de conexão para o Autonomous Database.

Use a view DBA_CONNECTION_TESTS para mostrar os testes de conexão disponíveis.

Por exemplo:

SQL> EXECUTE 
   dbms_app_cont_admin.add_sql_connection_test('SELECT COUNT(1) FROM DUAL');
SQL> EXECUTE 
   dbms_app_cont_admin.enable_connection_test(dbms_app_cont_admin.sql_test, 
                                             'SELECT COUNT(1) FROM DUAL');
SQL> SELECT * FROM DBA_CONNECTION_TESTS;

Configure o mesmo teste de conexão que está ativado no seu banco de dados no pool de conexões ou no servidor de aplicativos. Configure também a descarga e destruição do pool em caso de falha no teste de conexão com pelo menos duas vezes o tamanho máximo do pool ou MAXINT.

Usar Testes de Conexão com o Driver Thin Java

Se você quiser usar testes de conexão que sejam locais para o driver e não puder usar o suporte completo ao FAN do UCP:

  • Ativar validate-on-borrow=true
  • Defina as propriedades do sistema Java:
    • -Doracle.jdbc.fanEnabled=true
    • -Doracle.jdbc.defaultConnectionValidation=SOCKET

Em seguida, use um dos seguintes testes:

  • java.sql.Connection.isValid(int timeout)
  • oracle.jdbc.OracleConnection.pingDatabase()
  • oracle.jdbc.OracleConnection.pingDatabase(int timeout)
  • Um HINT no início do SQL de teste:
    • /*+ CLIENT_CONNECTION_VALIDATION */

Usar Testes de Conexão com o Driver OCI

Se quiser usar o driver do OCI diretamente, use OCI_ATTR_SERVER_STATUS. Esse é o único método que é uma alteração de código. Em seu código, verifique o identificador do servidor ao pedir emprestado e retornar conexões para ver se a sessão está desconectada. Durante a manutenção, o valor de OCI_ATTR_SERVER_STATUS é definido como OCI_SERVER_NOT_CONNECTED. Ao usar o pool de sessões do OCI, essa verificação de conexão é feita para você.

A amostra de código a seguir mostra como usar o OCI_ATTR_SERVER_STATUS: 

ub4 serverStatus = 0OCIAttrGet((dvoid *)srvhp,
          OCI_HTYPE_SERVER,             
        (dvoid *)&serverStatus, (ub4 *)0, OCI_ATTR_SERVER_STATUS,
      errhp);if (serverStatus ==
        OCI_SERVER_NORMAL)printf("Connection is
        up.\n");else if (serverStatus ==
        OCI_SERVER_NOT_CONNECTED) printf("Connection is down.\n");

Etapas para Usar a Continuidade de Aplicativos

Execute estas etapas para usar a Continuidade de Aplicativos:

  • Como pré-requisito, ative e configure a Continuidade de Aplicativos ou a Continuidade Transparente de Aplicativos (TAC) para seu serviço de banco de dados no Autonomous Database. Consulte Configurar Continuidade de Aplicativos no Autonomous Database para obter mais informações.

  • A Oracle recomenda que você use os drivers mais recentes do cliente. Os drivers do cliente 19c do Oracle Database e, posteriormente, fornecem suporte completo para a Continuidade de Aplicativos (AC) e para a Continuidade Transparente de Aplicativos (TAC). Use um dos seguintes drivers de clientes suportados:

    • Oracle JDBC Replay Driver 19c ou mais recente. Este é um recurso do driver JDBC fornecido no Oracle Database 19c para Continuidade de Aplicativos

    • Oracle Universal Connection Pool (UCP) 19c ou mais recente com o Oracle JDBC Replay Driver 19c ou mais recente

    • Oracle Weblogic Server 12c com Active GridLink ou servidores aplicativos JDBC de terceiros usando UCP com o Driver de Repetição JDBC Oracle 19c ou mais recente

    • Pools de conexão Java ou aplicativos Java independentes usando o Oracle JDBC Replay Driver 19c ou mais recente

    • Pool de Sessões do Oracle Call Interface 19c ou posterior.SQL*Plus 19c (19.8) ou posterior

    • ODP.NET em pool, Driver Não Gerenciado 19c ou mais recente ("Pooling=true" padrão na 12.2 e mais recente)

    • Aplicativos baseados no Oracle Call Interface que usam o driver OCI 19c ou mais recente

Retornar Conexões ao Pool de Conexões

O aplicativo deve retornar a conexão ao pool de conexões Oracle em cada solicitação. A melhor prática para uso do aplicativo é efetuar check-out (empréstimo) das conexões apenas pelo tempo necessário e, em seguida, fazer check-in no pool quando concluído para as ações atuais. Isso é importante para o melhor desempenho do aplicativo no runtime, para rebalanceamento do trabalho no runtime e durante eventos de manutenção e failover. Esta prática também é importante para a drenagem.

Ao usar um pool de conexões da Oracle, como Universal Connection Pool (UCP) ou OCI Session Pool, ou ODP.Net Unmanaged Provider ou ao usar o Active GridLink WebLogic, seguir esta prática incorpora limites de solicitação que o Application Continuity usa para identificar locais seguros para retomar e encerrar a captura. Isso é necessário para a Continuidade de Aplicativos e é recomendado para a Continuidade Transparente de Aplicativos.

Além disso, a Continuidade Transparente de Aplicativos descobrirá limites de solicitação se um pool não estiver em uso ou quando a repetição estiver desativada. As condições para descobrir um limite são:

  • Nenhuma transação aberta
  • Os cursor são retornados ao cache de instruções ou cancelados
  • Não existe estado de sessão não restaurável (consulte Estado de Sessão Limpa entre Solicitações neste documento)

Ativar Mutáveis Usados 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 de funções mutáveis é fornecido para SYSDATE, SYSTIMESTAMP, SYS_GUID e sequência.NEXTVAL. Se os valores originais não forem mantidos e valores diferentes forem retornados ao aplicativo na repetição, a repetição será rejeitada.

Se você precisar de mutáveis para PL/SQL, emita GRANT KEEP conforme necessário.

Por exemplo:

SQL> GRANT KEEP DATE TIME to adb_user;
SQL> GRANT KEEP SYSGUID to adb_user;
SQL> GRANT KEEP SEQUENCE mySequence to adb_user on mysequence.myobject;

Efeitos Colaterais

Quando uma solicitação de banco de dados inclui uma chamada externa, como o envio de MAIL ou a transferência de um arquivo, isso é denominado efeito colateral.

Os efeitos colaterais são ações externas, eles não revertem. Quando a repetição ocorre, há uma escolha sobre se os efeitos colaterais devem ser repetidos. Muitos aplicativos optam por repetir efeitos colaterais, como lançamentos e envio de e-mail, pois execuções duplicadas não causam problemas. Para a Continuidade de Aplicativos, os efeitos colaterais são repetidos, a menos que a solicitação ou a chamada do usuário seja explicitamente desativada para repetição. Por outro lado, como a Continuidade Transparente de Aplicativos está ativada por padrão, o TAC não reproduz efeitos colaterais. A captura é desativada e reativa o próximo limite implícito criado pelo TAC.

Melhores Práticas do Desenvolvedor para Disponibilidade Contínua

Siga estas melhores práticas para codificar a disponibilidade contínua no Autonomous Database.

Retornar Conexões ao Pool de Conexões

A prática mais importante do desenvolvedor é retornar conexões ao pool de conexões no final de cada solicitação. Isso é importante para o melhor desempenho do aplicativo no runtime, para drenar o trabalho e para rebalancear o trabalho no runtime e durante a manutenção e para entregar eventos de failover. Alguns aplicativos têm uma falsa ideia de que manter conexões melhora o desempenho. Manter uma conexão não executa nem dimensiona.

Limpar Estado da Sessão entre Solicitações

É uma prática recomendada limpar o estado da sessão entre as solicitações do banco de dados.

Quando um aplicativo retorna uma conexão com o pool de conexões, os cursores com status FETCH e o estado da sessão definido nessa sessão permanecem no lugar, a menos que uma ação seja tomada para limpá-los. Se o seu aplicativo estiver definindo o estado, é recomendável retornar seus cursores ao cache de instruções e limpar o estado da sessão relacionada ao aplicativo para evitar vazamento para reutilizações posteriores dessa sessão do banco de dados. Limpar o estado da sessão garante que o TAC possa descobrir limites.

Para limpar automaticamente seu estado entre solicitações com o Oracle Database 23ai, defina o atributo de serviço RESET_STATE=LEVEL1. Isso evitará o vazamento de estado e a extração de cursores pelo uso posterior do pool de conexões.

Se você estiver usando o Oracle Database 19c, use DBMS_SESSION.RESET_PACKAGE para limpar variáveis globais PL/SQL, use TRUNCATE para limpar tabelas temporárias, SYS_CONTEXT.CLEAR_CONTEXT para limpar o contexto e cancelar seus cursores retornando-os ao cache de instruções.

Se seu aplicativo não tem monitoramento de estado, como REST, APEX, Microsserviço e a maioria dos aplicativos Web, é recomendável usar o RESET_STATE.

Não incorporar COMMIT no PL/SQL e Evitar COMMIT no Sucesso e no COMMIT Automático

É recomendável usar um commit de nível superior (OCOMMIT, COMMIT() ou OCITransCommit). Se o seu aplicativo estiver usando COMMIT incorporado em PL/SQL, AUTOCOMMIT ou COMMIT ON SUCCESS, talvez não seja possível recuperar após uma interrupção ou timeout. O PL/SQL não é reintegrante. Depois que um commit no código PL/SQL for executado, esse bloco PL/SQL não poderá ser reenviado. Os aplicativos precisam cancelar a seleção do commit, o que não é válido, pois esses dados podem ter sido lidos, ou usar em batch um ponto de verificação e uma técnica de reinicialização. Ao usar AUTOCOMMIT ou COMMIT ON SUCCESS, a saída é perdida.

Se seu aplicativo estiver usando um commit de nível superior, haverá suporte total para TAC (Transparent Application Continuity), AC (Application Continuity) e TAF Select Plus. Se o seu aplicativo estiver usando COMMIT incorporado no PLSQL, AUTOCOMMIT ou COMMIT ON SUCCESS, talvez não seja possível repetir os casos em que a chamada, incluindo o COMMIT, não foi executada até a conclusão.

Usar ORDER BY ou GROUP BY em Consultas

O Application Continuity garante que o aplicativo veja os mesmos dados na repetição. Se os mesmos dados não puderem ser restaurados, a Continuidade de Aplicativos não aceitará a repetição. Quando uma ordem SELECT usa ORDER BY ou GROUP BY é preservada. No Autonomous Database, o otimizador de consulta geralmente usa o mesmo caminho de acesso, o que pode ajudar na mesma ordem dos resultados. O Application Continuity também usa uma cláusula AS OF para retornar os mesmos resultados de consulta em que AS OF é permitido.

Considerações sobre o SQL*Plus

O SQL*Plus geralmente é nossa ferramenta para testar as coisas. O SQL*Plus, é claro, não reflete nosso aplicativo real que será usado na produção, portanto, é sempre melhor usar o pacote de teste de aplicativo real para testar seu plano de failover e medir sua proteção. O SQL*Plus não é um aplicativo em pool, portanto, não tem limites de solicitação explícitos. Alguns aplicativos usam o SQL*Plus, por exemplo, para relatórios. Para usar o SQL*Plus com failover, verifique o seguinte:

  1. O FAN é sempre ativado para o SQL*Plus. Use a string de conexão recomendada que configura automaticamente os pontos finais do ONS para você.

  2. Ao usar SQL*plus, a chave é minimizar os round-trips para o banco de dados: https://blogs.oracle.com/opal/sqlplus-12201-adds-new-performance-features

  3. O SQL*Plus é suportado para TAC, começando com o Oracle Database 19c. Para obter melhores resultados, defina um tamanho de matriz grande. Por exemplo (defina arraysize 1000). Evite ativar o serveroutput, pois isso cria um estado de sessão não restaurável.