Retorne Conexões ao Pool de Conexão

O aplicativo deve retornar a conexão com o pool de conexões em cada solicitação. É prática recomendada que um aplicativo faça check-out de uma conexão apenas pelo tempo necessário. Reter uma conexão em vez de retorná-la ao pool não funciona. Portanto, um aplicativo deve fazer check-out de uma conexão e, em seguida, fazer check-in dela imediatamente após a conclusão do trabalho. As conexões estarão disponíveis para uso posterior de outros threads ou do seu thread quando necessário novamente. É uma recomendação geral retornar conexões para um pool de conexões, independentemente de você usar FAN ou testes de conexão para drenagem.

Usar um Pool de Conexões Oracle

É recomendável usar um pool de conexões Oracle sensível ao FAN 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 e ODP.NET. Nenhuma alteração de aplicativo é necessária para usar o FAN que não seja garantir que suas conexões sejam retornadas para o pool entre as solicitações.

Usar UCP com um Pool de Conexões de Terceiros

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 pelo UCP. Muitos servidores de aplicativos suportam essa abordagem, 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 usar um Pool Oracle com o protocolo FAN, o Autonomous Database ou os drivers clientes fornecidos drenarão a sessão. Quando os serviços são realçados ou interrompidos durante a manutenção ou há um switchover para um site stand-by usando o Autonomous Data Guard, os drivers do Oracle Database e do cliente Oracle procuram locais seguros para liberar as conexões de acordo com as seguintes regras:

• Testes de conexão padrão para validade de conexão emprestada ou retornada de um pool de conexões
• Testes SQL personalizados para validade de conexão
• Limites de solicitações estão em vigor e a solicitação atual foi encerrada

Retorne Conexões ao Pool de Conexão

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

Ao usar um pool de conexões Oracle, como o UCP (Universal Connection Pool) ou o Pool de Sessões do OCI, ou o Provedor Não Gerenciado ODP.Net, ou ao usar o Active GridLink WebLogic, após essa prática, incorpora limites de solicitações que o AC (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.

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

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

Ativar Mutables 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 das funções mutáveis é fornecido para SYSDATE, SYSTIMESTAMP, SYS_GUID e sequence.NEXTVAL. Se os valores originais não forem mantidos e valores diferentes forem retornados para o aplicativo na reprodução, a reprodução será rejeitada.

Se você precisar de mutáveis para PL/SQL, execute 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 enviar E-MAIL ou transferir um arquivo, isso é denominado efeito colateral.

Os efeitos colaterais são ações externas que não podem ser revertidas. Quando a reprodução ocorre, há uma opção sobre se os efeitos colaterais devem ser reproduzidos. Muitos aplicativos escolhem repetir efeitos colaterais, como lançamentos e envio de e-mail, já que execuções duplicadas não causam problemas. Para o AC (Application Continuity), os efeitos colaterais serão reproduzidos, a menos que a solicitação ou a chamada do usuário seja explicitamente desativada para reprodução. Por outro lado, como a Continuidade Transparente de Aplicativos está ativada por padrão, o TAC não reproduz os efeitos colaterais. A captura é desativada e reativada no próximo limite implícito criado pelo TAC.

Retorne Conexões ao Pool de Conexão

A prática mais importante do desenvolvedor é retornar conexões para o pool de conexões no fim de cada solicitação. Isso é importante para melhor desempenho do aplicativo no runtime, para trabalho de drenagem e de rebalanceamento no runtime e durante manutenção e para tratar eventos de failover. Alguns aplicativos têm uma falsa ideia de que reter as conexões melhora o desempenho. A retenção de uma conexão não funciona nem é escalada.

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 para o pool de conexões, os cursores no status FETCH e o estado da sessão definido nessa sessão permanecem em vigor, a menos que seja executada uma ação para limpá-los. Se seu aplicativo estiver definindo o estado, é prática recomendada retornar seus cursores para o cache de instruções e limpar o estado da sessão relacionado ao aplicativo para evitar vazamento para reutilizações posteriores dessa sessão de banco de dados. A limpeza do estado da sessão garante que o TAC possa descobrir limites.

Para limpar automaticamente o 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 e SYS_CONTEXT.CLEAR_CONTEXT para limpar o contexto e cancelar seus cursores retornando-os para o cache de instruções.

Se o seu aplicativo não tiver monitoramento de estado, como REST, APEX, Microservice e a maioria dos aplicativos web, a melhor prática será usar RESET_STATE.

Não inclua COMMIT no PL/SQL e Evite COMMIT em caso de Sucesso e COMMIT Automático

A prática recomendada é usar um commit de nível superior (OCOMMIT, COMMIT() ou OCITransCommit). Se o seu aplicativo estiver usando COMMIT incorporado em PL/SQL ou AUTOCOMMIT ou COMMIT ON SUCCESS, pode não ser possível recuperar após uma interrupção ou um timeout. PL/SQL não é reentrante. Depois que um commit em PL/SQL é executado, esse bloco PL/SQL não pode ser submetido novamente. Os aplicativos precisam cancelar a seleção do commit, o que não está correto, pois esses dados podem ter sido lidos ou, para batch, usar uma técnica de checkpoint e reinicialização. Ao usar AUTOCOMMIT ou COMMIT ON SUCCESS, a saída é perdida.

Se o seu aplicativo estiver usando um commit de nível superior, haverá suporte total para Continuidade Transparente de Aplicativos (TAC), AC (Application Continuity) e TAF Select Plus. Se o seu aplicativo estiver usando COMMIT incorporado em PLSQL, AUTOCOMMIT ou COMMIT ON SUCCESS, talvez não seja possível reproduzir os casos em que a chamada que inclui 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 reprodução. Se não for possível restaurar os mesmos dados, o AC (Application Continuity) não aceitará a reprodução. Quando um SELECT usa ORDER BY ou GROUP BY, a ordem é preservada. No Autonomous Database, o otimizador de consulta geralmente usa o mesmo caminho de acesso, 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 costuma ser nossa ferramenta de teste O SQL*Plus, é claro, não reflete nosso aplicativo real que será usado em produção. Por isso, sempre é melhor usar a suíte real de testes de aplicativos para testar seu plano de failover e medir sua proteção. O SQL*Plus não é um aplicativo em pool; por isso, não tem limites explícitos de solicitações. Alguns aplicativos usam o SQL*Plus, por exemplo, para relatórios. Para usar o SQL*Plus com failover, verifique o seguinte:

1. O FAN está 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 o SQL*plus, a chave é minimizar round-trips para o banco de dados: https://blogs.oracle.com/opal/sqlplus-12201-adds-new-performance-features

3. Existe suporte para o SQL*Plus para TAC desde o Oracle Database 19c. Para obter melhores resultados, defina um tamanho de array grande. Por exemplo (defina o tamanho do array como 1000). Evite ativar a saída do servidor, uma vez que isso cria um estado de sessão não restaurável.