java.sql.SQLException:- ORA-01000:cursores abertos máximos excedidos

1. 
   Erro de configuração
   
   • Você tem mais threads em seu aplicativo consultando o banco de dados do que cursores no banco de dados. Um caso é quando você tem uma conexão e um pool de threads maiores que o número de cursores no banco de dados.
   • Você tem muitos desenvolvedores ou aplicativos conectados à mesma instância de banco de dados (o que provavelmente incluirá muitos esquemas) e, juntos, você está usando muitas conexões.
   • 
     Solução:
     
     • Aumentar o número de cursores no banco de dados (se os recursos permitirem) ou
     • Diminuindo o número de threads no aplicativo.
2. 
   Vazamento do cursor
   
   • Os aplicativos não estão fechando ResultSets (em JDBC) ou cursores (em procedimentos armazenados no banco de dados)
   • Solução :Vazamentos de cursor são bugs; aumentar o número de cursores no banco de dados simplesmente atrasa a falha inevitável. Vazamentos podem ser encontrados usando análise de código estático, JDBC ou registro em nível de aplicativo e monitoramento de banco de dados.

Plano de fundo

O que é um cursor?

Encontrar e definir o número de cursores

ALTER SYSTEM SET OPEN_CURSORS=1337 SID='*' SCOPE=BOTH;

Relacionando JDBC na JVM a cursores no banco de dados

• JDBC Conexão é a representação do cliente de um banco de dados sessão e fornece banco de dados transações . Uma conexão pode ter apenas uma única transação aberta por vez (mas as transações podem ser aninhadas)
• Um ResultSet JDBC é suportado por um único cursor no banco de dados. Quando close() é chamado no ResultSet, o cursor é liberado.
• Um JDBC CallableStatement invoca um procedimento armazenado no banco de dados, muitas vezes escrito em PL/SQL. O procedimento armazenado pode criar zero ou mais cursores e pode retornar um cursor como um JDBC ResultSet.

Fechando objetos JDBC

Statement stmt = conn.createStatement();
try {
    ResultSet rs = stmt.executeQuery( "SELECT FULL_NAME FROM EMP" );
    try {
        while ( rs.next() ) {
            System.out.println( "Name: " + rs.getString("FULL_NAME") );
        }
    } finally {
        try { rs.close(); } catch (Exception ignore) { }
    }
} finally {
    try { stmt.close(); } catch (Exception ignore) { }
}

• Se você simplesmente fechar o ResultSet sem tentar {} catch {}, ele poderá falhar e impedir que a instrução seja fechada
• Queremos permitir que qualquer exceção gerada no corpo da tentativa seja propagada para o chamador. Se você tiver um loop, por exemplo, criando e executando instruções, lembre-se de fechar cada instrução dentro do loop.

Retendo objetos JDBC

• Use instância de objeto ou membros de classe para armazenar objetos JDBC que são reutilizados várias vezes por um período mais longo, como Connections e PreparedStatements
• Use variáveis ​​locais para ResultSets, pois eles são obtidos, repetidos e fechados normalmente dentro do escopo de uma única função.

• Somente o servidor de aplicativos cria threads (com os quais lida com solicitações recebidas)
• Somente o servidor de aplicativos cria conexões (que você obtém do pool de conexões)
• Ao salvar valores (estado) entre chamadas, você deve ter muito cuidado. Nunca armazene valores em seus próprios caches ou membros estáticos - isso não é seguro em clusters e outras condições estranhas, e o Application Server pode fazer coisas terríveis com seus dados. Em vez disso, use beans com estado ou um banco de dados.
• Em particular, nunca mantenha objetos JDBC (Connections, ResultSets, PreparedStatements, etc) em diferentes invocações remotas - deixe o Application Server gerenciar isso. O Application Server não apenas fornece um pool de conexões, mas também armazena em cache suas PreparedStatements.

Eliminando vazamentos

1. 
   Durante o desenvolvimento - detectar bugs cedo é de longe a melhor abordagem:
   
   1. 
      Práticas de desenvolvimento:As boas práticas de desenvolvimento devem reduzir o número de bugs em seu software antes que ele saia da mesa do desenvolvedor. As práticas específicas incluem:
      
      1. Programação em pares, para educar aqueles sem experiência suficiente
      2. Revisões de código porque muitos olhos pensam melhor que um
      3. Teste de unidade, o que significa que você pode exercitar toda e qualquer base de código a partir de uma ferramenta de teste que torna a reprodução de vazamentos trivial
      4. Use bibliotecas existentes para pool de conexões em vez de criar suas próprias
   2. 
      Análise de código estático:Use uma ferramenta como o excelente Findbugs para realizar uma análise de código estático. Isso pega muitos lugares onde o close() não foi tratado corretamente. Findbugs tem um plug-in para Eclipse, mas também é executado de forma autônoma, possui integrações no Jenkins CI e outras ferramentas de compilação
      
2. 
   Em tempo de execução:
   
   1. 
      Capacidade de retenção e compromisso
      
      1. Se a capacidade de retenção do ResultSet for ResultSet.CLOSE_CURSORS_OVER_COMMIT, o ResultSet será fechado quando o método Connection.commit() for chamado. Isso pode ser definido usando Connection.setHoldability() ou usando o método sobrecarregado Connection.createStatement().
   2. 
      Registro em tempo de execução.
      
      1. Coloque boas instruções de log em seu código. Estes devem ser claros e compreensíveis para que o cliente, a equipe de suporte e os colegas de equipe possam entender sem treinamento. Eles devem ser concisos e incluir a impressão dos valores de estado/internos de variáveis ​​e atributos-chave para que você possa rastrear a lógica de processamento. Um bom registro em log é fundamental para depurar aplicativos, especialmente aqueles que foram implantados.
      2. 
         Você pode adicionar um driver JDBC de depuração ao seu projeto (para depuração - não o implante). Um exemplo (não usei) é log4jdbc. Você então precisa fazer uma análise simples neste arquivo para ver quais execuções não têm um fechamento correspondente. A contagem de aberturas e fechamentos deve destacar se há um problema em potencial
         
         3. Monitorando o banco de dados. Monitore seu aplicativo em execução usando ferramentas como a função 'Monitor SQL' do SQL Developer ou o TOAD da Quest. O monitoramento é descrito neste artigo. Durante o monitoramento, você consulta os cursores abertos (por exemplo, da tabela v$sesstat) e revisa seu SQL. Se o número de cursores está aumentando e (mais importante) se tornando dominado por uma instrução SQL idêntica, você sabe que tem um vazamento com esse SQL. Pesquise seu código e revise.

Outros pensamentos

Você pode usar WeakReferences para lidar com o fechamento de conexões?