Perguntas Frequentes

Abrir tudo Fechar tudo
  • O que há de novo na versão 19c?

    Atualizado em 5 de janeiro de 2022

    Este documento contém respostas às perguntas mais frequentes sobre os drivers JDBC da Oracle. Este documento aborda as perguntas técnicas específicas e é usado para documentar soluções para perguntas frequentes de clientes, bem como quaisquer problemas conhecidos. Consulte o Guia de Referência do JDBC e Javadoc do JDBC para informações mais detalhadas.

    A seção abaixo destaca os principais recursos do JDBC da versão 19c. Consulte Revendo o Desempenho e a Escalabilidade das Aplicações Java que usam RDBMS para mais detalhes.

    • Padrões Java mais recentes: Suporta JDK17, JDK11, JDK8 e é compatível com JDBC 4.3 (ojdbc11.jar e ojdbc10.jar) e JDBC 4.2 (ojdbc8 .jar) pelo driver JDBC e pool de conexão universal (ucp.jar)

    • Conexão: Easy Connect Plus para conexões TCPS mais fáceis e propriedades de conexão passageiras (apenas 19c), novo arquivo ojdbc.properties para definir as propriedades da conexão, várias maneiras de definir TNS_ADMIN, nome de domínio (DN) do servidor de configuração como uma propriedade de conexão e suporte de uma nova propriedade de carteira (my_wallet_directory);
    • Desempenho: Reactive Streams Ingest (RSI) para streaming de dados no Oracle Database (21c e posterior); Oracle Connection Manager (CMAN) no modo diretor de tráfego (CMAN-TDM)
    • Alta Disponibilidade: Continuidade Transparente de Aplicações (TAC), suporte para AC em DRCP e suporte para AC para os tipos Oracle JDBC legados implementados como classes Java concretas
    • Escalabilidade: afinidade de dados do Oracle RAC e APIs de roteamento de shards para camadas intermediárias
    • Segurança: Resolução automática de provedor para OraclePKIProvider, suporte para Key Store Service (KSS) e suporte para proxy HTTPS
    • Tipos de dados: Acessibilidade a matrizes associativas PL/SQL, Oracle REF CURSOR como parâmetro de ligação IN e validação de tipo de dados JSON
  • Existe algum documento relacionado ao Oracle Database Cloud Service para desenvolvedores de Java?

    Para desenvolvedores de Java que usam o driver JDBC e/ou UCP, as instruções detalhadas para se conectar com o serviço de banco de dados na nuvem estão presentes na página JDBC com DB Cloud.

JDBC em Geral

Perguntas Específicas sobre Versão

  • Quais versões dos drivers JDBC são compatíveis?

    Consulte a tabela abaixo para ver as versões compatíveis dos drivers JDBC. As informações nesta tabela fornecem o resumo para maior comodidade. Recomendamos que você consulte a página 6 da Política de suporte vitalício para mais detalhes e atualizações.

    Versão Data da disponibilidade geral Término do Suporte Premier Término do suporte estendido Término do suporte de manutenção
    21c (Versão de Inovação) Agosto de 2021 Julho de 2027 Não disponível Indefinido
    19c (Versão de Longo Prazo) Abril de 2019 Dezembro de 2029 (Consulte a Política de Suporte Vitalício) Dezembro de 2032 Indefinido
    18c Julho de 2018 Junho de 2021 Não disponível Indefinido
    12.2 Março de 2017 30 de novembro de 2020 (período limitado de correção de erros para 12.2.0.1 - 1º de dezembro de 2020 - 31 de março de 2022) Não disponível Indefinido
    EE 12.1 Junho de 2013 Julho de 2018 Julho de 2022 Indefinido
  • O que é a matriz de interoperabilidade JDBC e RDBMS ou a matriz de certificação?

    Consulte a tabela que aborda a matriz de interoperabilidade do driver JDBC para ver as versões compatíveis do banco de dados Oracle. A recomendação é que a versão do driver JDBC seja sempre igual ou superior à versão do banco de dados Oracle para aproveitar os recursos mais recentes do driver.

    Matriz de Interoperabilidade Banco de Dados 23.x Banco de Dados 21.x Banco de Dados 19.x Banco de Dados 18.3 Banco de Dados 12.2 e 12.1
    JDBC 23.x Sim Sim Sim Não Não
    JDBC 21.x Sim Sim Sim Foi Foi
    JDBC 19.x Sim Sim Sim Foi Foi
    JDBC 18.x Não Foi Foi Foi Foi
    JDBC 12.2 e 12.1 Não Foi Foi Foi Foi
    Foi: Uma combinação que foi suportada em algum momento, mas uma das versões não é mais coberta por nenhum suporte Premier, suporte para correção de erros primários, suporte estendido ou suporte de manutenção estendido. As correções não são mais possíveis.
  • Quais são as versões do Oracle JDBC e as do JDK?

    O driver Oracle JDBC é sempre compatível com a versão mais recente do JDK em todas as versões novas. Em algumas versões, os drivers JDBC são compatíveis com várias versões do JDK. Use a tabela abaixo para escolher o driver JDBC correto com base na sua versão de preferência do JDK.

    Versão do Oracle Database Arquivos JAR do JDBC específicos da versão
    23.x ojdbc17.jar com JDK17, JDK19 e JDK21 (23.6 ou posterior)
    ojdbc11.jar com JDK11
    ojdbc8.jar com JDK8 e JDK11
    21.x ojdbc11.jar com JDK11, JDK17, JDK19 e JDK21 (21.17 em diante)
    ojdbc8.jar com JDK8 e JDK11
    19.x ojdbc10.jar com JDK11, JDK17, JDK19 e JDK21 (19.25 ou posterior)
    ojdbc8.jar com JDK8, JDK11, JDK17, JDK19 e JDK21 (19.25 ou posterior)
    18.x ojdbc8.jar com JDK8 e JDK11
    12.2 ou 12cR2 ojdbc8.jar com JDK8
    12.1 ou 12cR1 ojdbc7.jar com JDK 7 e JDK 8
    ojdbc6.jar com JDK 6
    11.2 ou 11gR2 ojdbc6.jar com JDK 6, JDK 7 e JDK 8
    (Observação: JDK7 e JDK8 são compatíveis apenas com as versões 11.2.0.3 e 11.2.0.4)
    ojdbc5.jar com JDK 5
  • Quais são as versões do Oracle JDBC e as especificações do JDK?

    A tabela lista os drivers JDBC da Oracle e as especificações do JDBC suportadas nessa versão.

    Versão do Oracle Database Conformidade da especificação do JDBC
    23.x e 21.x JDBC 4.3 no ojdbc11.jar
    JDBC 4.2 no ojdbc8.jar
    19.x JDBC 4.3 no ojdbc10.jar
    JDBC 4.2 no ojdbc8.jar
    18.3 JDBC 4.2 no ojdbc8.jar
    12.2 ou 12cR2 JDBC 4.2 no ojdbc8.jar
    12.1 ou 12cR1 JDBC 4.1 no ojdbc7.jar
    JDBC 4.0 no ojdbc6.jar
    11.2 ou 11gR2 JDBC 4.0 no ojdbc6.jar
    JDBC 3.0 no ojdbc5.jar
  • Os drivers Oracle JDBC são certificados em OpenJDK?
     

    Os drivers Oracle JDBC são certificados apenas com o Oracle JVM (anteriormente Sun JVM). No entanto, os clientes têm usado drivers Oracle JDBC com JVMs não Oracle (por exemplo, IBM JVM). A única ressalva é que para que a equipe de desenvolvimento do Oracle JDBC e o suporte da Oracle considerem um problema relacionado aos drivers Oracle JDBC, exigiremos que tal problema seja reproduzido no Oracle JVM.

  • Qual é o driver JDBC 19.x recomendado para ser usado com o JDK11?     

    A versão 19.x tem
    (a) ojdbc8.jar (compilado com o JDK8 (JDBC 4.2) e pode ser usada com o JDK9, JDK11) e
    (b) ojdbc10.jar (compilado com o JDK10 (JDBC 4.3) e pode ser usada com o JDK11).
    Se você estiver usando o JDK11, o ojdbc8.jar ainda será uma opção melhor, pois inclui todos os recursos da versão 4.3, mas como extensões Oracle. Os clientes só poderão usar o ojdbc10.jar se precisarem de recursos do JDBC 4.3 disponíveis no Java SE padrão.
    Exemplo:
    ojdbc8.jar:
    Connection conn = DriverManager.getConnection(. . .);    // conn.beginRequest(); falha porque beginRequest não está no Java 8  ((OracleConnection)conn).beginRequest(); // é estabelecida porque beginRequest é fornecido como uma extensão Oracle

    ojdbc10.jar:
    Connection conn = DriverManager.getConnection(. . .);  conn.beginRequest(); // succeeds because beginRequest is in Java 10        ((OracleConnection)conn).beginRequest(); // succeeds because OracleConnection supports JDBC 4.3 (in Java 10) and beginRequest is part of JDBC 4.3
  • E quanto à versão do JDBC que não está listada na tabela acima?

    Se ela não estiver listada na tabela acima, verifique com seu canal de suporte se você ainda está no contrato de suporte das versões mais antigas.

  • Onde eu consigo os arquivos jar do JDBC?

    Faça download do jar do JDBC necessário e de outros arquivos jar complementares, como orai18n.jar, oraclepki.jar, osdt_core.jar, osdt_cert.jar, na Página de Download do JDBC da Oracle Technology Network.

  • Para que servem os diferentes arquivos JAR na página de download do driver JDBC 19.x?

    Consulte a tabela abaixo para saber mais detalhes sobre os drivers JDBC.

    • ojdbc10-full.tar.gz: Este arquivo contém o driver JDBC Thin 19.x mais recente (ojdbc10.jar), o Universal Connection Pool (ucp.jar), os arquivos Readme e os arquivos jar complementares.
    • ojdbc8-full.tar.gz: Este arquivo contém o driver JDBC Thin mais recente 19.x (ojdbc10.jar), o Universal Connection Pool (ucp.jar), os arquivos Readme e os arquivos jar complementares.
    • ojdbc10.jar: Com certificação do JDK11 e JDK10, todas as classes suportarão a funcionalidade básica do driver Thin. Ao utilizar alguns recursos, outros arquivos jar são necessários
    • ojdbc8.jar: com certificação do JDK9 e JDK8, todas as classes suportarão a funcionalidade básica do driver Thin. Ao utilizar alguns recursos, outros arquivos jar são necessários
    • ucp.jar: Universal Connection Pool (UCP) que fornece os recursos do pool de conexões.
    • oraclepki.jar, osdt_core.jar e osdt_cert.jar: arquivos jar adicionais necessários para acessar o Oracle Wallets no Java
    • orai18n.jar: Para uso pelo daemon Oracle Notification Services (ONS)
    • simplefan.jar: APIs Java para se inscrever em eventos RAC pelo ONS
    • xbd6.jar: Classes que suportarão a interface JDBC 4.x java.sql.SQLXML padrão
    • ojdbc8_g.jar: O mesmo que ojdbc8.jar, exceto que compilado com a opção -g para incluir informações de depuração e com chamadas java.util.logging incluídas.
    • ojdbc8dms.jar: O mesmo que ojdbc8.jar, exceto que inclui código para suportar o Oracle Dynamic Monitoring Service (DMS). Também inclui suporte para registros em log do JDBC. Este arquivo só pode ser usado quando dms.jar também estiver no caminho de classe. O arquivo dms.jar não é enviado como parte do produto RDBMS. Ele só está disponível como parte do produto Oracle Application Server.
    • ojdbc8dms_g.jar: O mesmo que ojdbc8dms.jar, exceto que compilado com a opção -g para incluir informações de depuração e com suporte completo para registros em log do JDBC.

Oracle JDBC em Geral

  • Quais são os diferentes drivers JDBC fornecidos pela Oracle?

    A Oracle fornece quatro tipos diferentes de drivers JDBC para uso em diferentes cenários de implementação. Embora todos os drivers Oracle JDBC sejam semelhantes, alguns recursos se aplicam apenas aos drivers JDBC OCI e outros se aplicam apenas ao driver JDBC Thin.

    • Driver JDBC Thin do lado do cliente: Este é um driver JDBC Tipo 4 que usa o Java para se conectar diretamente com a Oracle. Ele implementa os adaptadores SQL*Net, Net8 e TTC da Oracle usando sua própria implementação de soquete Java baseada em TCP/IP. O driver JDBC Thin não requer que o software do cliente Oracle seja instalado, mas requer que o servidor seja configurado com um listener TCP/IP. Recomendamos que todos os nossos clientes usem o driver JDBC Thin, pois a maioria dos novos recursos é desenvolvida apenas nesse driver. Como ele é totalmente escrito em Java, esse driver não depende de plataforma.
    • Driver JDBC Thin do lado do servidor: Este é um driver JDBC Tipo 4 que usa o Java para se conectar diretamente com a Oracle. Este driver é usado internamente no banco de dados Oracle. Este driver oferece a mesma funcionalidade que o driver JDBC Thin do lado do cliente (acima), mas é executado em um banco de dados Oracle e usado para acessar bancos de dados remotos. Como ele é totalmente escrito em Java, esse driver não depende de plataforma.
    • Driver JDBC OCI do lado do cliente (descontinuado): Esse é um driver JDBC Tipo 2 que usa métodos nativos do Java para chamar pontos de entrada em uma biblioteca C subjacente. Essa biblioteca C, chamada de OCI (Oracle Call Interface), interage com um banco de dados Oracle. O driver JDBC OCI requer que o cliente Oracle instale a mesma versão do driver.

      Observação: O driver Oracle JDBC-OCI ou o driver cliente tipo 2 foram descontinuados. Consulte a nota MOS 2953282.1 para o aviso de descontinuação.

    • Driver JDBC interno do lado do servidor: Este é um driver JDBC Tipo 2 que usa métodos nativos do Java para chamar pontos de entrada em uma biblioteca C subjacente. Essa biblioteca C faz parte do processo do servidor Oracle e se comunica diretamente com o mecanismo SQL interno nas chamadas, evitando qualquer tráfego de rede. Isso permite que o código Java executado no servidor acesse o banco de dados subjacente da maneira mais rápida possível. Ele só pode ser usado para acessar o mesmo banco de dados. O uso de métodos nativos torna a plataforma de driver JDBC interno do lado do servidor específica. Esse driver interno do lado do servidor é totalmente consistente com os drivers do lado do cliente e oferece suporte aos mesmos recursos e extensões.
  • Qual driver usar?

    A melhor opção é usar o driver Oracle JDBC Thin Todos os novos aprimoramentos e recursos são implementados somente no driver JDBC Thin.

    Se você estiver usando uma rede que não seja TCP/IP, deverá usar o driver OCI.

    Para processamento no local na sessão do banco de dados (ou seja, Java no banco de dados), você deve usar o driver integrado tipo 2 (ou o driver interno do servidor). Se o código java em execução na sessão precisar acessar um banco de dados Oracle remoto ou outra sessão na mesma instância de banco de dados, você deverá usar o driver integrado tipo 4 (ou o driver thin do servidor).

  • E quanto aos arquivos jar do Driver Thin do Servidor e o Driver Interno do Servidor?

    Os dois drivers são executados apenas na VM Java do servidor Oracle e suas classes são instaladas como parte da instalação da VM. Não há arquivos de classes separados disponíveis ou necessários para esses drivers. Confira a referência em InternalT2Driver.java e InternalT4Driver.java.

  • Os fornecedores de terceiros podem distribuir os drivers JDBC da Oracle juntamente com seus próprios softwares?

    Se você for uma empresa de software de terceiros (e parceira da Oracle), verifique a licença FUTC e execute-a pelo seu departamento jurídico. Depois, entre em contato com o representante de vendas local da Oracle para mais detalhes.

  • Quais permissões os drivers Oracle JDBC exigem?

    Quando sua aplicação é executada com uma opção SecurityManager ativada (que deve estar em produção), determinadas operações são privilegiadas. Para executar essas operações, o código deve receber as permissões apropriadas.

    A maneira de descobrir quais permissões conceder é checar o arquivo ojdbc.policy na página de download. Este é um arquivo de política de segurança genérico que você pode usar para conceder aos drivers todas as permissões necessárias. Na maioria dos casos, você vai querer comentar muitas das permissões, pois sua aplicação não usa os recursos que requerem essas permissões.

    Este arquivo depende de várias propriedades do sistema. Para usá-lo, você precisará definir essas propriedades usando a opção -D para o comando java.

    Algumas permissões só precisam ser concedidas ao código do driver JDBC. As operações que exigem essas permissões ficam entre um bloco doPriviliged. Outras permissões também devem ser concedidas ao código que chama os drivers. Essas operações não ficam entre blocos doPriviliged. Um exemplo notável é que o código que faz a chamada precisa da permissão de abrir soquete ao usar o driver Thin para abrir uma conexão. Isso evita que códigos não autorizados usem os drivers para um ataque de negação de serviço, entre outros motivos.

Instalação

  • Como instalar o driver Thin?

    Faça download do driver Oracle JDBC que está em conformidade com a versão do JDK que você está usando. Você encontra as versões mais recentes do driver JDBC na página de download.. Não se esqueça de incluir os drivers JDBC no caminho de classe. Consulte Quais são os diferentes arquivos JAR na página de download? para determinar os arquivos necessários para você.

  • Como instalar o driver Thin?

    O driver JDBC OCI geralmente requer que o cliente Oracle instale a mesma versão do driver. Porém, o driver JDBC OCI está disponível para instalação com o recurso OCI Instant Client, que não requer uma instalação completa do cliente Oracle. Consulte a documentação sobre a instalação do OCI Instant Client.

  • Como instalar o driver Interno do lado do servidor ou o Thin no driver do servidor?

    Você não faz a instalação. Esses dois drivers são instalados como parte da instalação do banco de dados. Se o banco de dados tiver sido instalado com o suporte Java, esses dois drivers já estarão instalados e disponíveis. Consulte É possível carregar um dos arquivos de classes na VM Java do servidor Oracle?

DriverManager e DataSources

  • Qual é a diferença entre DriverManager e DataSource?

    A primeira versão do JDBC especificada usando a classe java.sql.DriverManager para criar Conexões. Isto se revelou insuficientemente flexível, e as versões posteriores da especificação JDBC definem uma maneira adicional de criar Conexões utilizando DataSources. Recomendamos usar DataSources.

    DataSources fornecem uma maneira mais flexível de criar Conexões. DataSources foram projetados para serem usados com a JNDI, mas você não precisa usar a JNDI para usar DataSources. DataSources podem fazer mais do que apenas criar novas conexões. Especificamente, um DataSource pode implementar um cache de conexão. DataSources agora são a maneira preferida de criar uma Conexão.

    A maneira mais simples de se conectar a partir de um DataSource é:

    

ds = new oracle.jdbc.pool.OracleDataSource(); 
ds.setURL(myURL); 
conn = ds.getConnection(user, password);
  • Qual pool de conexões usar?

    Use o Universal Connection Pool (UCP). Esse novo mecanismo de cache de conexão não depende de driver, protocolo e banco de dados. Ele suporta conexões que não são do JDBC e conexões JDBC com bancos de dados que não a Oracle. Ao usar o Oracle JDBC, ele fornece recursos avançados da Oracle, como:

    • atributos de conexão para dividir e reutilizar conexões
    • um gerenciador de cache de conexão por VM para gerenciar um ou mais caches de conexão
    • timeout de conexão abandonada para recuperar conexões inativas com check-out etc.
    • Balanceamento de Carga de Conexão de Runtime para alocar trabalho às instâncias com melhor desempenho

    O suporte para o Cache de Conexão Implícita Oracle foi retirado. O suporte para o antigo cache de conexão, OracleConnectionCacheImpl, foi retirado na versão 11.1.

  • O que é o Pool de Conexões do JDBC OCI?

    O Pool de Conexões do JDBC OCI serve para agrupar várias sessões com monitoramento de estado com poucas conexões físicas subjacentes ao banco de dados. A conexão é vinculada à sessão somente durante a chamada. O elemento do pool é a conexão física subjacente. As sessões da aplicação podem migrar (internamente) para qualquer conexão física subjacente disponível.

    Cada conexão física do pool tem uma sessão interna adicional para o servidor. Portanto, você pode ver mais sessões no servidor.

Conexões

  • Qual é o formato de um URL?

    O formato geral de um URL é

    jdbc:oracle:<drivertype>:<username/password>@<database>

    O <drivertype>

    • thin
    • oci
    • kprb

    O <username/password> fica vazio ou é do formulário

    <username>/<password>

    Em um URL como

    o nome de usuário e senha ficam vazios, enquanto este URL

    jdbc:oracle:thin:@mydatabase

    não especifica um nome de usuário e uma senha. Ao usar este formulário, o nome de usuário e a senha devem ser fornecidos de outra forma.

  • Qual é o formato da descrição <database>

    A descrição <database> depende um pouco do tipo de driver. Se o tipo de driver for kprb, a descrição <database> fica vazia. Se o tipo de driver for OCI e você quiser usar uma conexão de transmissão, a descrição <database> fica vazia. Caso contrário (o driver thin ou oci e não a transmissão), a descrição do banco de dados será uma das seguintes opções:

    • //<host>:<port>/<service>
    • <host>:<port>:<SID>
    • <TNSName>

    O URL a seguir conecta o usuário scott com a senha tiger a um banco de dados com o serviço orcl (Importante: veja mais sobre serviços) por meio da porta 1521 do host myhost usando o driver Thin.

    jdbc:oracle:thin:scott/tiger@//myhost:1521/orcl

    Esse URL se conecta ao mesmo banco de dados usando o driver OCI e o SID inst1 sem especificar o nome de usuário ou a senha.

    jdbc:oracle:oci:@myhost:1521:inst1

    Este URL se conecta ao banco de dados chamado GL no arquivo tnsnames.ora usando o driver Thin e sem nome de usuário ou senha especificados. O nome de usuário e a senha devem ser especificados em outro lugar.

    jdbc:oracle:thin:@GL

    O suporte ao uso de entradas TNSNAMES com o driver Thin é novo na versão 10.2.0.1.0. Para que isso funcione, você precisa ter configurado o arquivo tnsnames.ora corretamente

  • Como usar o argumento Properties?

    Além do URL, use um objeto da classe Java Properties padrão como entrada. Por exemplo:

    

  java.util.Properties info = new java.util.Properties(); 
info.put ("user", "scott"); 
info.put ("password","tiger"); 
info.put ("defaultRowPrefetch","15"); 
getConnection ("jdbc:oracle:oci:@",info);

    Todas as propriedades suportadas estão definidas no JavaDoc para oracle.jdbc.OracleConnection. Há constantes que definem os nomes das propriedades. O JavaDoc de cada constante descreve o que a propriedade faz e como usá-la.

    Nas versões anteriores à 11.1 do driver, as propriedades estão definidas no JavaDoc para oracle.jdbc.pool.OracleDataSource.setConnectionProperties e no Guia do Desenvolvedor do Oracle JDBC.

  • Não é necessário registrar a classe OracleDriver no DriverManager?

    Não é mais necessário registrar a classe OracleDriver para se conectar com o driver Interno do lado do servidor, embora não tenha problema fazer isso. Isso é válido se você estiver usando getConnection() ou defaultConnection() para fazer a conexão.

    Se você estiver usando o ojdbc6.jar e o JSE 6 ou mais recente, não precisará registrar o driver, independentemente do driver que estiver usando. A partir do JSE 6, a Interface do Provedor de Serviço Java padrão registra os drivers automaticamente. Basta chamar DriverManager.getConnection e o runtime encontrará o driver e o registrará para você.

  • Qual nome de usuário e senha devem ser usados ao conectar com o Driver Interno do servidor?

    Qualquer nome de usuário ou senha que você incluir na string de URL será ignorado ao se conectar com a conexão padrão do servidor. O método DriverManager.getConnection() retorna um novo objeto Java Connection sempre que você o chama. Embora o método não esteja criando uma nova conexão de banco de dados (somente uma única conexão implícita é usada), ele retorna um novo objeto java.sql.Connection.

    Novamente, quando o código JDBC está sendo executado dentro do servidor de destino, a conexão é um canal de dados implícito, e não uma instância de conexão explícita de um cliente. Ela jamais pode ser encerrada.

  • Vejo o erro OutofMemory quando defino um valor de pré-extração padrão mais alto.

    A solução é aumentar o tamanho da inicialização (-ms) e o tamanho máximo (-mx) do pool de alocação de memória. Isso não será um problema com os drivers 11.1 e mais recentes, pois eles usam menos memória do que os drivers de 10g. Você pode encontrar uma discussão mais detalhada sobre esse problema no artigo técnico “Gerenciamento da memória do JDBC” na página da Web do JDBC OTN.

  • O que é uma string de conexão de serviço?

    A Oracle está substituindo o mecanismo SID para identificar bancos de dados por uma nova abordagem de serviços. Isso está disponível no banco de dados desde 8.1.wi7. O JDBC suporta serviços no URL de conexão. Incentivamos fortemente todos a fazerem a transição de SIDs para serviços o mais rápido possível, já que os SIDs deixarão de ser suportados em uma das próximas versões do banco de dados.

    O formato básico de um URL de serviço é:

    jdbc:oracle:thin:[<user>/<password>]@//<host>[:<port>]/<service> jdbc:oracle:oci:[<user>/<password>]@//<host>[:<port>]/<service>

    Exemplos:

    jdbc:oracle:thin:@//myserver.com/customer_db jdbc:oracle:oci:scott/tiger@//myserver.com:5521/customer_db

    Para mais informações, consulte o Guia do Usuário do JDBC.

  • Como me conectar como SYSDBA ou SYSOPER?

    A única maneira de fazer isso é usar o objeto Properties ao se conectar, em vez de especificar o nome de usuário e a senha como strings. Coloque o nome de usuário na propriedade "user" e a senha na propriedade "password". Em seguida, coloque o modo na propriedade "internal_logon". Mais ou menos assim:

    

Properties props = new Properties(); 
props.put("user", "scott"); 
props.put("password", "tiger"); 
props.put("internal_logon", "sysoper"); 
Connection conn = DriverManager.getConnection (url, props);

    Ao se conectar como SYSDBA ou SYSOPER usando o driver Thin, o RDBMS deve ser configurado para usar um arquivo de senha. Consulte “Como criar e manter um arquivo de senha” no “Guia do Administrador do Oracle Database”.

  • Quais métodos de criptografia são suportados pelos drivers Oracle JDBC?

    O driver JDBC OCI suporta os mesmos algoritmos que o servidor de banco de dados.

    Nas versões 11.1 e 11.2, o driver JDBC Thin suporta:

    • RC4_40
    • RC4_56
    • RC4_128
    • RC4_256
    • DES40C
    • DES56C
    • 3DES112
    • 3DES168
    • SSL
    • AES256
    • AES192
    • AES128
  • Como ativar a criptografia e a soma de verificação com o driver JDBC Thin?

    Supondo que o servidor esteja configurado corretamente, use as seguintes propriedades de conexão:

    

Properties props = new Properties(); 
props.put("oracle.net.encryption_types_client", "(3DES168)"); 
props.put("oracle.net.encryption_client", "REQUIRED"); 
props.put("oracle.net.crypto_checksum_types_client", "(MD5)"); 
props.put("oracle.net.crypto_checksum_client", "REQUIRED");
  • O que é a autenticação de proxy?

    A autenticação de proxy é a capacidade de se conectar como usuário através de outro usuário. Por exemplo, a autenticação de proxy permite que a camada intermediária faça a autenticação uma vez no banco de dados usando uma conta “genérica” e estabeleça uma sessão básica em nome dos usuários reais. Consulte JavaDoc para oracle.jdbc.OracleConnection.openProxySession.

  • Os drivers Oracle JDBC suportam SSL?

    Sim, mas o suporte é específico do driver. A criptografia SSL tem suporte no driver JDBC OCI desde o Oracle JDBC 9.2.x e é suportada no driver THIN a partir da versão 10.2.

  • Os drivers Oracle JDBC suportam LDAP no URL de conexão?

    Sim. O driver JDBC THIN suporta LDAP e LDAP comum na SSL no URL de conexão, por exemplo, ao usar o Oracle Internet Directory como um provedor de LDAP. Consulte o Guia do Desenvolvedor do Oracle JDBC e o Guia do Administrador do Oracle Net Services para mais detalhes.

  • Como usar o JDBC para me conectar com um servidor de banco de dados protegido por um firewall?

    Geralmente, é recomendável que o Oracle Connection Manager seja usado para fazer proxy de suas conexões por meio do firewall. Abra uma porta designada para ser usada pelo Oracle Connection Manager e deixe que a solução cuide do resto. Você não deve abrir diretamente uma porta que o listener do banco de dados esteja usando, como a porta 1521.

    Consulte o Guia do Administrador do Oracle Net Services para descobrir como configurar o Oracle Connection Manager.

Statements, PreparedStatements, CallableStatements

  • O que é defineColumnType e quando usar?

    defineColumnType é uma extensão do Oracle JDBC que oferece maior desempenho em alguns casos. Em versões anteriores do Oracle JDBC, todos os drivers se beneficiavam de chamadas para defineColumnType, mas a partir da versão 10.1.0, o driver Thin não precisa mais das informações fornecidas. O driver Thin alcança desempenho máximo sem chamadas para defineColumnType. Os drivers OCI e os drivers internos do lado do servidor ainda têm um melhor desempenho quando a aplicação utiliza defineColumnType.

    Se seu código for usado com os drivers Thin e OCI, você poderá desativar o método defineColumnType ao usar o Thin definindo a propriedade de conexão disableDefineColumnType como "true". Isso transformará defineColumnType em uma NOOP. Não defina essa propriedade de conexão ou defina-a como "false" ao usar os drivers OCI ou drivers internos do lado do servidor.

    defineColumnType também pode ser usada para alterar o tipo dos dados ou limitar o tamanho dos dados de tamanho variável.

    Há uma nova variação com um quarto parâmetro para form_of_use.

  • defineColumnType força as conversões no Servidor?

    Não para o driver Thin e sim para os drivers OCI e drivers internos do lado do servidor.

  • Como desativar EscapeProcessing no nível do driver JDBC em vez de chamar stmt.setEscapeProcessing(false) no código da aplicação?

    Use uma propriedade "CONNECTION_PROPERTY_PROCESS_ESCAPES" em OracleConnection.

  • Os drivers Oracle JDBC forneceram um recurso Vincular por Nome?

    Sim. Consulte JavaDoc para oracle.jdbc.OraclePreparedStatement. Procure os métodos setXXXAtName. Além disso, oracle.jdbc.OracleCallableStatement permite vincular argumentos a procedimentos PL/SQL pelos nomes de argumentos formais. Verifique o JavaDoc dos métodos oracle.jdbc.OracleCallableStatement.setXXX(String, ...).

    É muito importante lembrar que setXXX(String, XXX) se vincula usando o nome do parâmetro formal do procedimento armazenado chamado. setXXXAtName(String, XXX) se vincula usando o nome do parâmetro de estilo Oracle ( :foo) na string SQL que está sendo executada. Eles são muito diferentes e podem dar resultados muito diferentes.

  • No caso de métodos setXXX em PreparedStatement, como os drivers JDBC da Oracle determinam o tipo de dados?

    Em geral, há um tipo de dados fixo associado a cada método setXXX que é o tipo de dados que mais corresponde ao tipo do argumento.

  • O que acontece se o tipo do parâmetro de destino não for o mesmo que o tipo presumido pelo método setXXX?

    Os dados são enviados ao servidor no formato do tipo de dados presumido e o servidor tenta convertê-los no tipo do parâmetro de destino. Se nenhuma conversão for possível, o servidor sinalizará um erro e o driver lançará uma SQLException no tempo de execução.

  • Por que os drivers não fazem a conversão no lado do cliente?

    Para instruções SQL, primeiro podemos ir até o servidor para ver as informações de tipo e então fazer as conversões, mas isso envolveria idas e voltas extras. O código é otimizado para o caso comum em que o programador JDBC utiliza a API mais apropriada para o tipo de coluna.

  • Quais são os tipos de dados de byte para inserir em uma coluna em uma tabela?

    Para dados de byte, existe três tipos de Oracle SQL: RAW, LONG RAW e BLOB. Os dados RAW têm tamanho limitado, são armazenados diretamente em uma coluna e transmitidos para o servidor em pacotes em linha. Os dados LONG RAW têm um limite muito maior (2 Gigabytes), são armazenados por meio de um mecanismo especial ao lado da linha e transmitidos ao servidor por meio de um mecanismo de chamada de retorno de fluxo. Os dados BLOB têm um tamanho ilimitado, são armazenados separadamente da tabela com apenas um localizador de LOB armazenado na tabela e são transmitidos para o servidor em operações separadas antes de o localizador ser armazenado em uma coluna na tabela.

  • Quais são os tipos de dados de caracteres para inserir em uma coluna em uma tabela?

    Para dados de byte, existe três tipos de Oracle SQL: VARCHAR2, LONG e CLOB. Os dados VARCHAR2 têm tamanho limitado, são armazenados diretamente em uma coluna e transmitidos para o servidor em pacotes em linha. Os dados LONG têm um limite muito maior (2 Gigabytes), são armazenados por meio de um mecanismo especial ao lado da linha e transmitidos ao servidor por meio de um mecanismo de chamada de retorno de fluxo. Os dados CLOB têm um tamanho ilimitado, são armazenados separadamente da tabela com apenas um localizador de LOB armazenado na tabela e são transmitidos para o servidor em operações separadas antes de o localizador ser armazenado em uma coluna na tabela.

  • Quais são os tamanhos para setString, setCharacterStream e setAsciiStream?
    Form Instru Driver Limite inferior Limite Superior Mecanismo de vinculação Observação
    Todos Todos Todos 0 0 Nulo  
    Todos SQL Cliente 1 caractere 32766 caracteres Direto  
                 
    Todos SQL Cliente 32767 caracteres 2147483647 bytes Streaming  
    Todos SQL Cliente 2147483648 bytes 2147483647 caracteres Clob Temporário  
    CARAC   Servidor 1 caractere 65536 bytes Direto 1, 2
    NCARAC     1 caractere 4000 bytes Direto  
    NCARAC     4001 bytes 2147483647 caracteres Clob Temporário  
    CARAC     65537 bytes 2147483647 bytes Streaming  
          2147483647 bytes 2147483647 caracteres Clob Temporário  
                 
    Todos PL/SQL Todos 1 caractere 32512 caracteres Direto  
    Todos PL/SQL Todos 32513 caracteres 2147483647 caracteres Clob Temporário  
  • Qual é o limite de tamanho para dados binários via setBytes e setBinaryStream?
    Instru Driver Limite inferior Limite Superior Mecanismo de vinculação Observação
    Todos Todos Todos 0 0 Nulo  
    Todos SQL Cliente 1 caractere 32766 caracteres Direto  
                 
    Todos SQL Cliente 32767 caracteres 2147483647 bytes Streaming  
    Todos SQL Cliente 2147483648 bytes 2147483647 caracteres Clob Temporário  
    CARAC   Servidor 1 caractere 65536 bytes Direto 1, 2
    NCARAC     1 caractere 4000 bytes Direto  
    NCARAC     4001 bytes 2147483647 caracteres Clob Temporário  
    CARAC     65537 bytes 2147483647 bytes Streaming  
          2147483647 bytes 2147483647 caracteres Clob Temporário  
    Todos PL/SQL Todos 1 caractere 32512 caracteres Direto  
    Todos PL/SQL Todos 32513 caracteres 2147483647 caracteres Clob Temporário  

    Observações:

    pode ser substituído por

    begin Insert into blob_tab (blob_col) values (? ); end;

    1. O driver interno do lado do servidor não pode converter dados dos parâmetros BLOB de instruções SQL maiores que 2000 bytes. Essa limitação não existe para instruções PL/SQL. Em muitos casos, isso pode ser usado como solução alternativa encapsulando o SQL em PL/SQL. Por exemplo, uma string Java insert into blob_tab (blob_col) values (?)
    2. O método específico da Oracle setBytesForBlob pode ser usado como uma solução alternativa.
  • Quais são os limites de tamanho para os métodos proprietários setBytesForBlob, setStringForClob em oracle.jdbc.OraclePreparedStatement?
    API FORM Instru Driver Limite inferior Limite Superior Mecanismo de vinculação Observação
    setBytesForBlob n/d Todos Todos 0 0 Nulo  
        Todos Cliente 1 byte 2000 bytes Direto  
        Todos Cliente 2001 bytes 21474836487 bytes Blob Temporário 2
    setStringForClob Todos Todos Todos 0 0 Nulo  
      Todos Todos Cliente 1 caractere 32766 caracteres Direto  
      Todos Todos Cliente 32767 caracteres 2147483647 caracteres Clob Temporário  
      Todos Todos Servidor 1 caractere 4000 bytes Direto  
      Todos Todos Servidor 4001 bytes 2147483647 caracteres Clob Temporário 1

    Observações:

    1. O método específico da Oracle setStringForClob pode ser usado como uma solução alternativa.
    2. O método específico da Oracle setBytesForBlob pode ser usado como uma solução alternativa.
  • Alternar os tipos de vinculação força uma análise adicional do servidor da instrução?

    Sim.

  • E quanto a CallableStatements e procedimentos com parâmetros IN OUT?

    É um requisito que os tipos de dados do parâmetro IN e OUT sejam os mesmos. A alternância automática causará conflitos, a menos que o código do usuário também altere o tipo em registerOutParameter. Uma abordagem melhor é não usar parâmetros IN OUT onde isso possa ser um problema. Para fazer isso, altere o procedimento original ou adicione um procedimento de wrapper ou um bloco PL/SQL que utiliza parâmetros IN e OUT separados.

  • A seleção de procedimentos PL/SQL polimórficos será alterada quando o tipo de vínculo mudar?

    Sim. Isso pode ser explorado no código PL/SQL.

  • E quanto ao código existente?

    O código existente continuará funcionando corretamente. Não há nenhuma mudança. Anteriormente, se uma entrada excedesse os limites de tamanho da API usada, uma SQLException seria lançada quando a API setXXX fosse chamada. Agora, a exceção ocorrerá no momento da execução, se ocorrer.

  • Em alguns casos, o driver cria lobs temporários. Ele os rastreia e os libera?

    Sim, eles são liberados após a próxima execução da instrução ou quando ela é fechada.

  • Estamos usando um conjunto de caracteres com largura variável, como UTF8. O driver corrige o tamanho do byte de uma sequência de caracteres?

    Sim. Exceto quando se escolhe alternar para Clob para as strings maiores, o que é feito presumindo o tamanho máximo.

  • É uma boa ideia usar, por exemplo, setString para uma string muito grande?

    Para começar, provavelmente não é uma boa ideia criar a string muito grande. Consulte a documentação dos fornecedores da Java Virtual Machine para saber os efeitos que objetos muito grandes têm no sistema de gerenciamento de memória Java.

  • Os tipos de coluna LONG RAW e LONG foram descontinuados. Por que há novos usos das APIs setXXXStream?

    As APIs de fluxo não foram descontinuadas. Elas oferecem melhor desempenho para algumas operações do que as APIs LOB e serão mantidas.

  • As APIs LOB são muito mais flexíveis, não é verdade?

    Com certeza! As APIs LOB permitem acesso aleatório a qualquer parte do LOB. Use-as quando apropriado.

  • Por que não posso criar um PreparedStatement que faça select * from tab where id in (?, ?, ?, ...)?

    O problema é que o RDBMS não suporta parâmetros de vinculação para os elementos na cláusula IN. Esta é uma limitação do banco de dados, não do driver.

ResultSets

  • O que significa "Exhausted Resultset: prepare_for_new_get"?

    Este erro acontece se você tentar usar um ResultSet depois de fechá-lo. Isso também acontece se você fechar a instrução que criou o ResultSet.

    ResultSet rset = stmt.executeQuery ("select ROWID from EMP"); ... rset.close (); // or stmt.close (); rset.getString (1);

  • Por que devo fechar ResultSets?

    A especificação original do JDBC exigia que Connections, Statements e ResultSets fossem fechados quando não fossem mais acessíveis. Isso requer o uso de finalizadores. Os finalizadores têm uma enorme penalidade de desempenho para todos os aspectos de uma aplicação executada em uma JVM com quaisquer finalizadores. A Sun não incentiva o uso de finalizadores. O encerramento automático demandaria o uso de finalizadores, o que seria ruim para todos os clientes, quer eles dependessem ou não do fechamento automático. Esta não é uma compensação aceitável.

    Até onde sabemos, nenhum driver JDBC de qualquer fornecedor implementa ou já implementou o fechamento automático pelo motivo descrito acima. Esse requisito foi removido da especificação, embora alguns resquícios dessa redação apareçam em alguns lugares e no Tutorial do JDBC. O tutorial, embora informativo e útil, não é definitivo. Ele não é atualizado há anos. A especificação do JDBC 4.0 não requer o fechamento automático de forma alguma.

    ResultSets, Statements e Connections utilizam recursos no lado do cliente e do servidor. Enquanto esses objetos estiverem abertos, os recursos associados estarão alocados. Os recursos são liberados somente quando os objetos são fechados. Se ResultSets, Statements, e/ou Connections não forem fechados, recursos serão vazados, afetando o desempenho da sua aplicação.

    Encerrar uma Conexão encerra todas as Instruções associadas. Encerrar uma Instrução encerrar todos os ResultSets associados. Portanto, se você terminar uma Conexão, poderá encerrá-la e todas as Instruções e ResultSets serão encerrados. Essa é uma prática de programação aceitável. Uma prática melhor é encerrar Instruções e ResultSets explicitamente em blocos finais. Isso deixa sua aplicação mais robusta e diminui a probabilidade de vazamentos de recursos porque evolui para atender aos requisitos em constante mudança.

    PreparedStatement ps = null; ResultSet rs = null; try { ps = conn.prepareStatement(sql); try { rs = ps.executeQuery(); while (rs.next()) { // process row } } finally { if (rs != null) rs.close(); } } finally { if (ps != null) ps.close(); }

Tipos de dados simples

  • Qual é o caso de DATE e TIMESTAMP?

    Esta seção está em tipos de dados simples. :-)

    Antes da versão 9.2, os drivers Oracle JDBC mapeavam o tipo SQL DATE para java.sql.Timestamp. Isso fazia um pouco de sentido porque o tipo SQL DATE da Oracle contém informações de data e hora, assim como java.sql.Timestamp. O mapeamento mais óbvio para java.sql.Date era um pouco problemático, pois java.sql.Date não inclui informações de hora. E acontecia que o RDBMS não suportava o tipo SQL TIMESTAMP; portanto, não houve problema com o mapeamento de DATE para Timestamp.

    Na versão 9.2, o suporte para TIMESTAMP foi adicionado ao RDBMS. A diferença entre DATE e TIMESTAMP é que TIMESTAMP inclui nanossegundos e DATE não. Portanto, a partir da versão 9.2, DATE é mapeado para Date e TIMESTAMP é mapeado para Timestamp. Infelizmente, se você estiver contando com valores DATE para conter informações de horário, há um problema.

    Há várias maneiras de resolver esse problema nas versões do driver de 9.2 a 10.2:

    • Altere suas tabelas para usar TIMESTAMP em vez de DATE. Isso provavelmente raramente será possível, mas é a melhor solução quando for.
    • Altere a aplicação para usar defineColumnType para definir as colunas como TIMESTAMP em vez de DATE. Há problemas com isso porque você não quer usar defineColumnType a menos que precise (consulte O que é defineColumnType e quando usar?).
    • Altere a aplicação para usar getTimestamp em vez de getObject. Essa é uma boa solução quando possível, no entanto, muitas aplicações contêm código genérico que depende de getObject, então ela nem sempre é possível.
    • Defina a propriedade de conexão V8Compatible. Isso diz aos drivers JDBC para usar o mapeamento antigo em vez do novo. Você pode definir essa sinalização como uma propriedade de conexão ou de sistema. A propriedade de conexão é definida adicionando-a ao objeto java.util.Properties passado para DriverManager.getConnection ou para OracleDataSource.setConnectionProperties. A propriedade do sistema é definida incluindo uma opção -D na linha de comando java.
      java -Doracle.jdbc.V8Compatible="true" MyApp

    A versão 11.1 do Oracle JDBC corrige esse problema. A partir dessa versão, o driver mapeia colunas SQL DATE para java.sql.Timestamp por padrão. Não há necessidade de definir V8Compatible para o mapeamento correto ser feito. V8Compatible está muito obsoleto. Não use-o. Se você o definir como verdadeiro, não prejudicará em nada, mas você deve parar de usá-lo.

    Embora raramente fosse usado dessa forma, V8Compatible não existia para corrigir o problema DATE para Date, mas para dar suporte à compatibilidade com bancos de dados 8i. Os bancos de dados 8i (e mais antigos) não suportavam o tipo TIMESTAMP. A definição de V8Compatible não só fazia SQL DATE ser mapeado para Timestamp quando lido no banco de dados, como também fazia com que todos Timestamps fossem convertidos em SQL DATE quando gravados no banco de dados. Como o 8i não é suportado, os drivers JDBC 11.1 não suportam este modo de compatibilidade. Por esse motivo, o suporte para V8Compatible foi removido.

    Como mencionado acima, por padrão, os drivers da versão 11.1 convertem SQL DATE em Timestamp ao ler no banco de dados. Esta sempre foi a coisa certa a fazer e a mudança no 9i foi um erro. Os drivers da versão 11.1 foram revertidos para o comportamento correto. Mesmo que você não tenha definido V8Compatible na aplicação, não verá nenhuma diferença no comportamento na maioria dos casos. Você poderá notar uma diferença se usar getObject para ler uma coluna DATE. O resultado será Timestamp em vez de Date. Como Timestamp é uma subclasse de Date, isso não costuma ser um problema. Pode ser que veja uma diferença se você dependia da conversão de DATE para Date para truncar o componente de hora ou se você fizer toString no valor. Caso contrário, a alteração será imperceptível.

    Se por algum motivo sua aplicação for muito sensível a essa alteração e você precisar ter o comportamento 9i-10g, há uma propriedade de conexão que você pode definir. Defina mapDateToTimestamp como falso, e o driver reverterá para o comportamento 9i-10g padrão e mapeará DATE para Date.

  • Qual é o valor mais longo que pode ser vinculado?
    Método Tipo de Coluna Tamanho máximo
    setBytes LONG 4 mil bytes
    setBytes LONG RAW 2G bytes
    setString LONG 32 mil caracteres (SetBigStringTryClob="false")
    4 mil caracteres (SetBigStringTryClob="true")
    setString CLOB 2G caracteres

    Na versão 9.2, setString() em um LONG pode inserir até 64 mil caracteres com o driver OCI e 4 mil caracteres com o driver Thin. Na versão 10.1.0, alteramos o limite dos dois drivers para 32 mil caracteres. Entendemos que reduzir o limite do driver OCI de 64 para 32 mil pode ser um problema para alguns clientes. No entanto, considerando a significativa melhoria do desempenho que essa mudança possibilitou e que a Oracle está recomendando fortemente que nossos clientes migrem de LONG para CLOB, decidimos que a mudança de arquitetura é necessária.

    Recomendamos aos clientes que precisam de setString() trabalhar com mais de 32 mil caracteres na migração de LONG para CLOB.

  • Por que o resultado da leitura de um TIMESTAMP WITH TIME ZONE é diferente?

    O comportamento antigo estava incorreto. Veja o bug 4322830.

    O comportamento antigo era construir um Timestamp que imprimia o mesmo valor do banco de dados. Mas como Timestamp está no fuso horário UTC, isso dava um valor de Timestamp deslocado do valor correto. 1o de janeiro de 2007 8h UTC não é o mesmo que 1o de janeiro de 2007 8h PST. Eles representam pontos diferentes no tempo.

    Se você lesse 1o de janeiro de 2007 8h PST no banco de dados, os drivers 9i e 10g construíam um Timestamp com o valor 1o de janeiro de 2007 8h UTC. Esse valor era impresso“corretamente”, ou seja, como “1o de janeiro de 2007 8h”, mas obviamente representava o instante no tempo errado. Os drivers 11.1 corrigem este bug.

Tipos de Dados Avançados (Objetos)

  • Como criar instâncias de ADTs?

    O JDBC 4.0 introduziu métodos de fábrica na interface Conexão para criar instâncias de ADTs. Esta é uma API muito melhor do que usar construtores. Nós incentivamos usar os métodos de fábrica o máximo possível. Nós iremos descontinuar os construtores muito em breve e gostaríamos de remover o suporte a eles o mais rápido possível.

    Como os métodos de fábrica padrão são introduzidos no JDBC 4.0, esses métodos só estão disponíveis nos drivers JSE 6 (ojdbc6.jar). Para criar tipos proprietários da Oracle, os métodos de fábrica são definidos em OracleConnection para o JSE 5 e JSE 6 (ojdbc5.jar e ojdbc6.jar). Mais uma vez, incentivamos fortemente usar os métodos de fábrica.

  • Por que o método de fábrica padrão createArrayOf não é suportado?

    O tipo de array padrão do SQL é anônimo, ou seja, o tipo "array of foo" não tem um nome. Apenas o tipo de elemento tem nome. No Oracle SQL, o tipo de array é nomeado. Na verdade, tipos de array anônimos não são suportados. Portanto, o método de fábrica padrão JDBC 4.0 usa o tipo de elemento como seu argumento e cria uma instância de um tipo de array anônimo. Os drivers Oracle JDBC definem um método proprietário da Oracle, createArray, que usa o nome de um tipo de array e retorna uma instância desse tipo de array nomeado. Isso é necessário pela maneira como o Oracle SQL é definido. Atualmente, o banco de dados Oracle não pode suportar o método createArrayOf padrão do JDBC 4.0.

BFILEs, BLOBs, CLOBs

  • O que DBMS_LOB.ERASE faz?

    Apenas “limpa” um segmento do CLOB. Ele *não* encurta o CLOB. O comprimento do CLOB é o mesmo antes e depois do APAGAR. Você pode usar DBMS_LOB.TRIM para encurtar um CLOB.

  • Posso usar oracle.sql.CLOB.putChars()?

    Sim, mas precisa confirmar que os argumentos de posição e tamanho estejam corretos. Você também pode usar a interface OutputStream recomendada que, por sua vez, chamará putChars para você.

  • O OCI fornece uma função para manipular um CLOB CharSetId. Qual é o equivalente do JDBC?

    No JDBC, os CLOBS estão *sempre* em USC2, que é o conjunto de caracteres Oracle correspondente ao tipo de "carac" Java. Portanto, não há equivalente para o CLOB CharSetId do OCI.

  • Escrever em BLOBS é mais lento do que inserir LONG RAWs?

    Depende. Quando se escreve valores pequenos, menos de 10 mil, LONG RAWs são mais rápidos. Ao escrever valores maiores, a diferença desaparece.

  • Por que vejo um erro ORA-03127 ao receber o LobLength no código de amostra do Stream?

    Esse é o comportamento correto. As colunas LONG não são “extraídas” no local (também conhecidas como na linha). Elas são extraídas do lugar e existem no pipe até que você as leia explicitamente. Nesse caso, recebemos LobLocator (getBlob()) e tentamos ver o tamanho desse LOB antes de lermos a coluna LONG. Como o pipe não é claro, é o caso da exceção acima. A solução seria concluir a leitura da coluna LONG antes de executar qualquer operação no BLOB.

  • Quando recebo um CLOB do banco de dados e o atualizo, às vezes minhas alterações não aparecem no banco de dados. Por quê?

    Os LOBs da Oracle usam a semântica de valor. Ao atualizar um LOB, você deve gravar o LOB novamente no banco de dados para ter certeza de ver as alterações. Por motivos técnicos, às vezes suas alterações são salvas mesmo sem gravar o LOB, mas não é possível prever quando é esse o caso; portanto, sempre grave o LOB.

Tipos REF

  • Como passar um oracle.sql.REF entre dois clientes JDBC diferentes (Clientes EJBs, JDBC etc.)? Como a classe REF não é serializável?

    Isso era verdade, mas não mais. O REF agora é serializável.

    A observação a seguir ainda poderá ser útil se você estiver usando uma versão mais antiga dos drivers Oracle JDBC em que os REFs não são serializáveis.

    Os constituintes importantes da classe REF são o array de bytes que representa a referência de objeto e o nome totalmente qualificado do tipo de objeto. Você pode usar uma classe como a classe "SomeREF" abaixo para conter os bytes e o nome do tipo de um objeto REF. Esta classe é serializável. Ela pode recriar o REF com seu método "toREF" que precisa de uma Conexão JDBC como parâmetro.

    public class SomeREF implements java.io.Serializable { String typeName; byte[] bytes; public SomeREF (oracle.sql.REF ref) throws SQLException { this.typeName = ref.getBaseTypeName (); this.bytes = ref.getBytes (); } public oracle.sql.REF toREF (Connection conn) throws SQLException { return new oracle.sql.REF (new oracle.sql.StructDescriptor (typeName,conn),conn, bytes); } }

  • Como criar um novo REF?

    Você pode executar consultas em uma tabela que contenha o REF para tipos de Objeto Oracle8, e o REF será materializado como objetos Java oracle.sql.REF pelo JDBC. O JDBC não suporta a criação de um novo REF do zero. Você precisa acessar o banco de dados e inserir o novo REF no SQL. Em seguida, você deverá selecionar o REF novamente e retorná-lo ao cliente.

    É mais fácil fazer isso com um bloco PL/SQL. Por exemplo, se você tiver as seguintes tabelas:

    create or replace type point as object (x number, y number); create table point_values_table of point; create table point_ref_table (p ref point); É possível inserir um novo valor de ponto em point_values_table, uma nova referência a esse valor na tabela point_ref_table e retornar a REF ao cliente com o código: oracle.jdbc.driver.OracleCallableStatement call = (oracle.jdbc.driver.OracleCallableStatement) conn.prepareCall ("declare x ref point; " + "begin insert into point_values_table p values (point(10, 20))" + " returning ref(p) into x; " + " ? := x; " + "end;"); call.registerOutParameter (1, oracle.jdbc.driver.OracleTypes.REF,"SCOTT.POINT"); call.execute (); oracle.sql.REF ref = (oracle.sql.REF)call.getObject (1);

Tipos OPAQUE

  • O que são os tipos OPAQUE?

    Os tipos TOPAQUE têm dados binários e métodos de suporte que são definidos em uma biblioteca de códigos nativa do servidor. Eles só estão disponíveis para uso interno da Oracle.

Origens da Linha

  • Quando eu defino o atributo de capacidade de rolagem após a execução, ele não tem nenhum efeito na rolagem do RowSet. Por quê?

    As propriedades de um bean podem ser classificadas como:

    • propriedades de criação de objeto
    • propriedades de runtime

    As propriedades de criação de objeto devem ser definidas antes da criação do objeto, pois são as principais propriedades para criar o objeto. As propriedades de runtime podem ser definidas a qualquer momento e alteram o comportamento do bean no runtime.

    Capacidade de rolagem, nome de usuário e senha são propriedades de criação de objetos. O status de confirmação automática, a contagem de pré-extrações e outros são propriedades de runtime. Normalmente, o objeto de plano de fundo aparece durante a execução/setCommand; portanto, todos os atributos de criação da Instrução devem ser definidos antes disso. Como um objeto de conexão é necessário para criar um URL de Instrução, nome de usuário, senha etc. são necessários para a criação e devem ser definidos antes de definir o Comando.

  • Posso serializar o objeto RowSet em um arquivo simples mesmo que RowSet contenha fluxos?

    Sim, os fluxos serializáveis permitem serializar o Objeto do fluxo em qualquer mídia serializável, como um arquivo simples, conexão de rede, etc. Esse recurso só se aplica a CachedRowSet. É possível criar um CachedRowSet em uma máquina em que os drivers JDBC estão presentes e depois passá-lo para um cliente remoto em que somente os binários do conjunto de linhas estejam presentes e não os binários do driver. O cliente remoto pode alterar o RowSet inserindo, excluindo ou atualizando e depois enviá-lo de volta ao local onde os drivers JDBC e os binários RowSet estão presentes para sincronizar os valores modificados no banco de dados.

Driver Thin

  • O Driver JDBC Thin pode ser usado para desenvolver aplicações Java?

    Sim, o Driver JDBC Thin pode ser usado para desenvolver aplicações Java. Ao contrário do driver JDBC OCI, o driver JDBC Thin só funciona com redes baseadas em TCP/IP. Os usuários que executam aplicações em redes que não são TCP/IP são incentivados a usar o driver JDBC OCI.

Driver Interno do Servidor

  • Quando usar o Driver Interno do Servidor?

    Você deve usar o Driver Interno do Servidor ao acessar o banco de dados em um Procedimento Armazenado Java. Um Procedimento Armazenado Java é um método Java que é executado no Oracle RDBMS da mesma forma que PL/SQL é executado no RDBMS. Como ele está sendo executado no RDBMS, ele está necessariamente executando em uma sessão do banco de dados. A conexão do Driver Interno do Servidor é o identificador para essa sessão do banco de dados. Portanto, se seu código estiver sendo executado em um Procedimento Armazenado Java e você quiser acessar o banco de dados, use o Driver Interno do Servidor, exceto nessas raras ocasiões em que você deve usar o Driver Thin do Servidor.

Driver Thin do Servidor

  • Quando usar o Driver Thin do Servidor?

    Em um Procedimento Armazenado Java, geralmente você deve usar o Driver Interno do Servidor. Ele se conecta à mesma sessão em que o procedimento armazenado está sendo executado. No entanto, talvez você queira se conectar a outro banco de dados ou a uma nova sessão no mesmo banco de dados. Em qualquer um desses dois casos, você usa o Driver Thin do Servidor.

Erros

  • DriverManager.getConnection gera o Erro: “Nenhum driver adequado”

    Confirme se o driver está registrado e se você está usando um URL de conexão consistente com seu driver JDBC. Consulte Usando os Drivers JDBC da Oracle para ver os valores corretos.

  • Mensagem de Erro: “UnsatisfiedLinkError com o driver OCI”

    Ao usar o Win NT ou Win95, a Java Virtual Machine se queixa de não poder carregar OCI73JDBC.DLL, quando uma das DLLs chamadas por OCI73JDBC.DLL não pode ser carregada. Os drivers JDBC OCI usam bibliotecas compartilhadas que contêm as partes do código C do driver. A biblioteca é OCI73JDBC.DLL para o programa cliente Oracle7. A biblioteca compartilhada normalmente é instalada em [ORACLE_HOME]\BIN quando você instala o driver JDBC pela distribuição. Verifique se o diretório está no seu CAMINHO. Leia a seção Instalação da documentação para mais detalhes.

    A biblioteca compartilhada também depende de outras bibliotecas. Se alguma dessas DLLs estiver ausente, você vai ver um erro informando que OCI73JDBC.DLL está ausente. O JDBC OCI7 requer os seguintes arquivos Oracle7: CORE35.DLL, CORE35O.DLL, NLSRTL32.DLL e ORA73.DLL

    A Java Virtual Machine (JavaSoft JDK) é JAVAI.DLL.

    O runtime do Microsoft Visual C++ é MSVCRT.DLL, MSVCRTI.DLL, MSVCRT20.DLL e MSVCRT40.DLL.

    Você pode encontrar a lista de DLLs dependentes acessando o programa Windows Explorer, clicando com o botão direito do mouse na DLL e escolhendo Exibição Rápida. A tela Exibição Rápida mostra, entre outras coisas, a Tabela de Importação que lista as DLLs dependentes. É possível reinstalar os arquivos de suporte necessários ausentes no CD de instalação da Oracle. Instale “Arquivos de Suporte necessários 7.3.4”, “SQL*Net Client 2.3.4” e “Adaptador de protocolo de TCP/IP 2.3.4 da Oracle”c.

  • Mensagem de erro: “ORA-1019: não foi possível alocar memória.”

    Você está usando o driver OCI8 em uma instalação do cliente Oracle7. Use o driver OCI7.

  • Mensagem de erro: “ORA-01000: número máximo de cursores abertos excedido”

    O número de cursores que um cliente pode abrir por vez em uma conexão é limitado (50 é o valor padrão). Você precisa fechar a instrução explicitamente usando o método stmt.close() para fechar e liberar os cursores.

    Se você não fechar esses cursores explicitamente, esse erro será gerado. Aumentar o limite de "OPEN_CURSORS" pode ajudar a evitar o problema por um tempo, mas isso apenas mascara o problema, não o resolve. É sua responsabilidade fechar explicitamente cursores que não são mais necessários.

  • Mensagem de Erro: “ORA-01002: extração fora de sequência”

    Por padrão, o AutoCommit é ativado em uma Conexão JDBC. No entanto, para usar um SQL que tenha “para atualização”, autoCommit precisa estar DESATIVADO.

    Portanto, a solução é definir autoCommit como falso.

  • Mensagem de Erro: “ORA-12705: valor do parâmetro NLS inválido ou desconhecido especificado”

    Tente definir NLS_LANG explicitamente. Se NLS_LANG não estiver definido ou estiver definido corretamente, talvez o cliente não seja Oracle7.3.4. Instale o Oracle7.3.4 no cliente.

  • Erro ao tentar recuperar o texto do erro ORA-12705.

    Não existe instalação da Oracle no cliente ou a instalação não foi concluída corretamente. Se ainda não tiver feito a instalação, use o CD de instalação comum do Servidor Oracle e faça uma instalação do "Cliente Oracle” para colocar o software necessário na máquina cliente. Se você já tiver feito isso, verifique se a instalação foi realmente concluída corretamente e, se necessário, remova e reinstale.

    Esse erro pode ser gerado ao fazer uma instalação do cliente e esquecer de definir ORACLE_HOME. Se você não tiver a variável de ambiente ORACLE_HOME, basta definir/exportar essa variável de ambiente para corrigir o problema, sem precisar reinstalar o cliente.

  • Mensagem de Erro: O Driver JDBC Thin mostra Erros de "caractere inválido" de Literais Unicode

    O driver JDBC Thin requer aspas duplas ao redor de literais que contêm caracteres Unicode. Por exemplo:

    ResultSet rset = stmt.executeQuery ("select * from \"\u6d82\u6d85\u6886\u5384\"");

  • As operações INSERT ou UPDATE são lentas

    Por padrão, o driver dá commit em todas as operações INSERT e UPDATE quando você executa a instrução. No JDBC, isso é conhecido como modo autoCommit. Você pode ter um melhor desempenho desativando autoCommit e usando instruções COMMIT explícitas. Use o ponto de entrada setAutoCommit da classe Conexão para desativar autoCommit:

    connection.setAutoCommit(falso); Consulte Atualizações em Lote na Documentação do JDBC para ver informações sobre as extensões Oracle para chamadas em lote para INSERT e UPDATE. Esses comandos em lote podem ser mais rápidos do que desativar autoCommit.

  • Mensagem de erro: "Conexão redefinida pelo sistema de mesmo nível"

    Geralmente, esse é o erro que você verá se o servidor cair enquanto você estiver conectado a ele. Você pode estar no processo de estabelecer uma conexão ou estar no meio de uma conexão estabelecida. Em ambos os casos, verifique os arquivos de log do servidor para ver quais erros e dumps de pilha foram gerados no servidor.

    Esse erro é diferente do que acontece se você tentar se conectar a uma porta errada/inválida ou mesmo a uma máquina. Você veria um erro diferente, não este. Ele também é diferente do erro que você veria se o servidor estivesse inativo e não aceitasse solicitações de conexão.

  • O que significa "violação do protocolo"?

    O driver Thin lança essa exceção quando lê algo no RDBMS que não estava esperando. Isso significa que o mecanismo de protocolo no driver Thin e o mecanismo de protocolo no RDBMS não estão em sincronia. Não há como se recuperar deste erro. A conexão está inativa. Tente fechá-la, mas isso provavelmente falhará também.

    Se você vir um caso de teste reproduzível que gere esse erro, registre um TAR no Suporte Global da Oracle. Certifique-se de especificar os números exatos da versão do driver JDBC e do RDBMS, incluindo quaisquer patches.

Programas de Demonstração

  • Existe algum programa de demonstração do JDBC?

    Sim. Consulte $ORACLE_HOME/jdbc/demo/demo.tar em sistemas UNIX e $ORACLE_HOME/jdbc/demo/demo.zip em sistemas Windows.

  • Como executar as demonstrações?

    Descompacte o arquivo demo.tar ou demo.zip file. Você verá um arquivo Samples-Readme.txt. Leia esse arquivo primeiro para ter uma visão geral das demonstrações do JDBC e, em seguida, execute Makefile no UNIX ou chame rundemo.bat no Windows.

  • O que fazer em caso de erro ao executar uma demonstração?

    As demonstrações do JDBC são executadas sem erro. Se um erro for gerado, isso provavelmente significa que há algum problema na sua configuração. Verifique:

    • o caminho da classe
    • as versões corretas do jdk
    • consulte Samples-Readme.txt, Makefile e cada arquivo .java para ver os requisitos pré-teste.

Oracle JDBC Trace Facility

  • O que é o JDBC Trace Facility?

    O JDBC Trace Facility é um auxílio de depuração de runtime integrado às versões anteriores do Oracle JDBC. Quando ativado, ele imprime mensagens sobre a execução do driver JDBC da Oracle. Normalmente, essas mensagens incluem entrada de método, valores de parâmetro, estado interno significativo, erros internos, saída de método e valores de retorno.

    A partir da versão 10.1.0, o Oracle Trace Facility só é suportado em classes12_g.jar e classes12dms_g.jar. Todos os drivers JDBC da Oracle que suportam JDK 1.4 e mais recentes usam o recurso de rastreamento integrado em java.util.logging. Consulte a seção em java.util.logging para ver informações sobre como obter informações de rastreamento ao usar o JDBC 11, ojdbc14_g.jar ou ojdbc14dms_g.jar.

    Se você estiver tendo dificuldade com sua aplicação JDBC, poderá achar o rastreamento útil. A maioria das mensagens são sobre métodos JDBC internos e, por isso, talvez não sejam claras. Ainda assim, talvez possam ajudar um pouco. Sugiro definir o volume de rastreamento como 1 para começar.

    Se você acha que há um bug no JDBC, o rastreamento pode nos ajudar a dar suporte a você. Nesse caso, deixe o volume de rastreamento no padrão. Devido à grande saída que ele produz, você precisará rastrear um pequeno caso de teste ou uma parte limitada de uma aplicação maior. Certifique-se de incluir o código apropriado antes da falha.

  • Como ativar o rastreamento JDBC antigo?

    Consulte a seção em java.util.logging para ver informações sobre como obter informações de rastreamento ao usar o JDBC 11.

    Para usar o JDBC Trace Facility, você deve usar um arquivo jar de depuração: classes12_g.jar ou classes12dms_g.jar. Se você tentar usar o rastreamento enquanto estiver usando um dos outros arquivos jar ou zip, verá uma mensagem de erro ou nenhuma saída.

    Há duas maneiras de controlar o rastreamento: de forma programática ou por meio de propriedades. A API programática permite ativar ou desativar o rastreamento e alterar outras propriedades enquanto a aplicação está sendo executada. Dado o grande volume de dados de rastreamento, geralmente é uma boa ideia ativar o rastreamento apenas para bits de código particularmente suspeitos. Se não for fácil alterar a origem da aplicação, você poderá controlar o rastreamento por meio de propriedades. Essas propriedades são lidas uma vez na inicialização da aplicação e não são lidas novamente. Você pode usar as propriedades e a API ao mesmo tempo. As propriedades definem o estado inicial e a API modifica esse estado.

    A maneira mais simples de ativar o rastreamento de forma programática é chamar

    oracle.jdbc.driver.OracleLog.startLogging(); Isso envia o rastreamento para System.out. Para desativá-lo, chame

    oracle.jdbc.driver.OracleLog.stopLogging(); Você também pode ativar o rastreamento definindo a propriedade do sistema oracle.jdbc.Trace como "true". java -Doracle.jdbc.Trace=true MyApp Definir qualquer uma das outras propriedades do JDBC Trace Facility descritas abaixo define implicitamente oracle.jdbc.Trace como "true".

  • Como controlar o volume de saída de rastreamento?

    Consulte a seção em java.util.logging para ver informações sobre como obter informações de rastreamento ao usar o JDBC 11.

    O JDBC Trace Facility pode produzir muitas saídas. A maneira mais simples de controlar o volume é ativar o rastreamento apenas quando necessário.

    oracle.jdbc.driver.OracleLog.startLogging(); myApp.suspectCode();

    oracle.jdbc.driver.OracleLog.stopLogging(); Muitas vezes, isso não é possível. Você também pode reduzir o número de mensagens de rastreamento definindo o volume de rastreamento. oracle.jdbc.driver.OracleLog.setLogVolume(1); O valor padrão é 2. O valor máximo é 3, mas esse valor não produz mais do que 2 no momento. O valor 1 é muito menor que o padrão.

    Você pode controlar o tamanho de cada linha definindo um tamanho de linha explícito ou alterando quais campos são impressos em cada linha. Para alterar o tamanho máximo da linha

    oracle.jdbc.driver.OracleLog.setMaxPrintBytes(100); ou java -Doracle.jdbc.MaxPrintBytes=100 MyApp

    Para controlar quais campos são impressos, você pode definir a propriedade oracle.jdbc.PrintFields.

    java -Doracle.jdbc.PrintFields=none MyApp Os valores válidos são:

    • none--apenas imprime a mensagem
    • default
    • thread - igual a default mais o nome do thread
    • all
  • Para onde vai a saída do rastreamento?

    Consulte a seção em java.util.logging para ver informações sobre como obter informações de rastreamento ao usar o JDBC 11.

    Por padrão, a saída do rastreamento vai para System.out. Você pode enviá-la para outro lugar com a propriedade oracle.jdbc.LogFile

    java -Doracle.jdbc.LogFile=/tmp/jdbc.log MyApp ou chamando a API setLogStream. oracle.jdbc.driver.OracleLog.setLogStream(System.err); Definir o fluxo de log também inicia o rastreamento. Você pode desativar o rastreamento definindo o fluxo de log como nulo.

  • Como posso desativar o DMS em um jar habilitado para DMS?

    Existe uma propriedade do sistema oracle.dms.console.DMSConsole. Se essa propriedade não estiver definida, o DMS estará ativo. Se for definida como oracle.dms.instrument_stub.DMSConsole, uma implementação de stub será usada, o que desativará efetivamente o DMS. Uma maneira de uma aplicação desativá-lo seria chamar

    System.setProperty( "oracle.dms.console.DMSConsole", "oracle.dms.instrument_stub.DMSConsole"); antes de executar qualquer código DMS. Outra forma seria usar a opção -D com a VM Java. java -Doracle.dms.console.DMSConsole=oracle.dms.instrument_stub.DMSConsole MyApp

Ferramentas e ambientes de desenvolvimento

  • Posso depurar programas do JDBC com o Symantec Visual Cafe?

    O Visual Cafe não é mais suportado.

  • Posso depurar programas do JDBC com o Microsoft's Visual J++?

    O Visual J++ não é mais suportado.

Recursos Suportados

  • Os Drivers JDBC podem acessar Procedimentos Armazenados PL/SQL?

    Sim, tanto o driver Oracle JDBC OCI quanto o driver JDBC Thin suportam a execução de procedimentos armazenados PL/SQL e blocos anônimos. Eles suportam a sintaxe de escape SQL:2003 e a sintaxe de escape da Oracle. As seguintes chamadas PL/SQL estão disponíveis em ambos os Drivers JDBC da Oracle:

    • SQL:2003 Syntax CallableStatement cs1 = conn.prepareCall ("{call proc (?,?)}"); CallableStatement cs2 = conn.prepareCall ("{? = call func (?,?)}");
    • Oracle Syntax CallableStatement cs1 = conn.prepareCall ("begin proc (:1,:2); end;"); CallableStatement cs2 = conn.prepareCall ("begin :1 := func (:2,:3); end;");
  • Os Drivers JDBC suportam streaming?

    Sim, tanto o Driver Oracle JDBC OCI quanto o Driver Thin JDBC suportam streaming de dados em qualquer direção entre o cliente e o servidor. Eles suportam todas as conversões de fluxo: binário, ASCII e Unicode. Para mais informações, leia o tutorial sobre fluxos na documentação do Driver Oracle JDBC.

  • Os Drivers JDBC suportam conjuntos de caracteres multibyte?

    Sim, tanto o Driver Oracle JDBC OCI quanto o Driver Thin JDBC suportam conjuntos de caracteres multibyte. Ambos podem acessar bancos de dados que usam qualquer conjunto de caracteres Oracle. Eles convertem caracteres multibyte em Unicode 1.2. O Driver JDBC OCI foi testado e suporta todos os conjuntos de caracteres europeus e asiáticos, incluindo chinês, japonês e coreano.

  • Os Drivers JDBC funcionam com firewalls?

    Sim, tanto o driver JDBC OCI quanto o driver JDBC Thin podem funcionar em uma Intranet e Extranet. Em uma implantação Extranet, os drivers podem ser usados com a maioria dos firewalls líderes do setor com certificação SQL*Net. Hoje, os seguintes fornecedores de firewall certificaram seus Firewalls com o SQL*Net:

    • Firewalls de Inspeção com Monitoramento de Estado: Firewalls dos Sistemas Checkpoint, SunSoft e CISCO.
    • Firewalls baseados em proxy: Firewalls da Milkyway Networks, Trusted Information Systems, Raptor, Secure Computing Corporation e Global Internet.
  • Os drivers JDBC da Oracle suportam TABLES/RESULT SETS/RECORDS/BOOLEANS PL/SQL?

    Não. Não é viável para os drivers Oracle JDBC suportarem argumentos de chamada ou retornarem valores dos tipos PL/SQL TABLE (agora conhecidos como tabelas indexadas), RESULT SET, RECORD ou BOOLEAN. No momento, não há planos para alterar isso. As pessoas são incentivadas a usar os tipos RefCursor, Oracle Collections e Structured Object.

    Como solução alternativa, você pode criar procedimentos de encapsulamento que tratam os dados como tipos suportados pelo JDBC.

    Por exemplo, para encapsular um procedimento armazenado que usa boolianos PL/SQL, você pode criar um procedimento armazenado que extrai um caractere ou um número do JDBC e o passa para o procedimento original como BOOLEAN ou, para um parâmetro de saída, aceita um argumento BOOLEAN do procedimento original e o passa como um CHAR ou NUMBER para JDBC. Da mesma forma, para encapsular um procedimento armazenado que utiliza registros PL/SQL, você pode criar um procedimento armazenado que trate um registro em seus componentes individuais (como CHAR e NUMBER). Para encapsular um procedimento armazenado que usa tabelas PL/SQL, você pode dividir os dados em componentes ou talvez usar tipos de coleta Oracle.

    Veja a seguir um exemplo de procedimento de encapsulamento PL/SQL MY_PROC para um procedimento armazenado PROC que utiliza BOOLEAN como entrada:

    PROCEDURE MY_PROC (n NUMBER) IS BEGIN IF n=0 THEN proc(false); ELSE proc(true); END IF; END; PROCEDURE PROC (b BOOLEAN) IS BEGIN ... END;

  • Existe suporte para failover?

    Sim. Quando você está se conectando a um servidor RAC, o Failover de Conexão Rápida responde rapidamente a eventos de falha. Esse novo recurso de Alta Disponibilidade independe do driver e funciona em conjunto com o cache de Conexão implícita e o RAC para fornecer máxima disponibilidade de conexões no cache. Isso é feito processando eventos inativos do RAC para remover conexões inválidas e eventos ativos para balancear a carga das conexões existentes.

    Se você estiver usando o driver OCI e precisar apenas de failover de consulta, considere o TAF. O TAF facilita principalmente o failover de consulta em uma aplicação. Ele não é um mecanismo geral de failover. O Failover de Conexão Rápida e o TAF não podem ser usados juntos. Somente um pode ser ativado e usado por vez.

  • Como os drivers JDBC suportam tipos de dados Oracle ROWID? O que isso tem a ver com getCursorName e setCursorName?

    Não oferecemos suporte aos pontos de entrada getCursorName e setCursorName JDBC. Oferecemos acesso a ROWIDs, que oferecem uma funcionalidade semelhante. O JDBC 4.0 define java.sql.Rowid, que é totalmente compatível com oracle.sql.ROWID e é suportado nos drivers JSE 6 (ojdbc6.jar).

    Se você adicionar a pseudocoluna ROWID a uma consulta, poderá recuperá-la no JDBC com o ponto de entrada ResultSet getString. Você também pode vincular um ROWID a um parâmetro preparedStatement com o ponto de entrada setString.

    Isso permite atualizações no local, como no seguinte exemplo:

    Na classe ResultSetMetaData, as colunas que contêm ROWIDs são reportadas com o tipo oracle.jdbc.driver.OracleTypes.ROWID, cujo valor é -8.

  • Como os drivers JDBC suportam tipos de dados Oracle REFCURSOR?

    O driver Oracle JDBC suporta variáveis de vinculação do tipo REFCURSOR. Um REFCURSOR é representado por um ResultSet do JDBC. Use o método getCursor do CallableStatement para converter um valor REFCURSOR retornado por um bloco PL/SQL em ResultSet. O JDBC permite que você chame um procedimento armazenado que executa uma consulta e retorna um conjunto de resultados. Transmita o CallableStatement correspondente a oracle.jdbc.driver.OracleCallableStatement para usar o método getCursor.

  • O ANO funciona com drivers JDBC?

    A partir da versão 9.2, os drivers OCI e Thin oferecem suporte para ANO.

    O ANO funciona nas versões 8.0.x e acima dos Drivers OCI 8.0.X. Para que esse recurso funcione corretamente, você precisa ter os conjuntos de patches mais recentes das versões 8.0.4, 8.0.5 e 8.0.6.

    Observação: Há um bug conhecido (no. 899424) nas versões 8.1.5 e 8.1.6sdk. Embora tenhamos uma correção de bug para esse erro, ela ainda não foi repassada e lançada como patch para todas as versões anteriores. Até o momento, esse bug ainda existe nas versões 8.1.5 e 8.1.6sdk.

    A correção de bug já está no código 8.1.6, então não é necessário nenhum patch para a versão 8.1.6. Seu código funcionará! Para mais informações, veja o bug no. 899424.

  • Posso serializar tipos de dados oracle.sql.*?

    Sim. Todas as classes oracle.sql.* que representam tipos de dados SQL são serializáveis.

  • Os Drivers JDBC suportam Objetos ou Coleções?

    Sim, os drivers Oracle JDBC suportam Objetos e Coleções. Eles são suportados desde a versão 8.1.5.

  • Posso usar WaitOption e AutoRollback?

    As opções de rollback WaitOption e AutoRollback para chamadas em lote foram descontinuadas e não estão mais disponíveis para uso. Não é mais possível usar os seguintes métodos:

    public void setAutoRollback (int autoRollback); public int getAutoRollback(); public void setWaitOption(int waitOption); public int getWaitOption();

  • Um Procedimento Armazenado Java em uma instância de banco de dados pode abrir uma conexão com outra instância de banco de dados?

    Sim, usando o driver Thin do servidor. Isso é possível desde a versão 8.1.6sdk.

    A única solução alternativa conhecida no momento é configurar a primeira instalação para usar DBLINKS ao entrar em contato com a segunda instalação. Isso faz os drivers JDBC pensarem que ele ainda está trabalhando na mesma instância e conta com o DBLINKS para cuidar dos detalhes. No entanto, pode haver problemas em usar DBLINKS em uma instalação do servidor MTS.

Desempenho

  • Qual é mais rápido, o driver Thin ou o driver OCI?

    Como sempre, depende. O driver Thin é mais rápido em algumas aplicações, o driver OCI é mais rápido em outras. A partir da versão 10.1.0, o driver Thin provavelmente é um pouco mais rápido do que o driver OCI. Nos casos em que o cliente e o servidor são do mesmo tipo de hardware e SO, o driver do OCI coloca um pouco menos de carga no RDBMS, mesmo que o cliente Thin seja mais rápido. As diferenças geralmente são pequenas, menos de 10%. A maioria de nossos clientes usa o driver Thin por causa de sua administração mais fácil. A milhagem pode variar.

  • O que é mais rápido, Statements ou PreparedStatements?

    Statements podem ser um pouco mais rápidas se você for executar o SQL apenas uma vez. PreparedStatements são muito mais rápidas quando o SQL é executado mais de uma vez. Se você estiver usando o cache de instruções, o que deve ser feito, obter uma instrução do cache será o mesmo que executar a mesma instrução.

    Em geral, recomendamos que você use PreparedStatements, principalmente se estiver enviando dados fornecidos pelo usuário no SQL. Ao vincular os dados a um parâmetro PreparedStatement, você pode impedir a maioria dos ataques de injeção do SQL. Qualquer vantagem de desempenho do uso de Statements é insignificante.

java.util.logging

  • Como usar java.util.logging para obter a saída de rastreamento dos drivers Oracle JDBC?

    Primeiro, você deve usar um arquivo jar que inclua o código de registro em log. O driver JDBC ojdbc8.jar não inclui nenhum código de registro em log. O arquivo jar DMS sem depuração, ojdbc8dms.jar, inclui alguns códigos de registro em log. Os arquivos jar de depuração, *_g.jar, incluem códigos de registro em long extensos. Certifique-se de que não haja outros arquivos jar do Oracle JDBC em seu caminho de classe.

    Em segundo lugar, você deve ativar o registro em log do Oracle JDBC. Você pode ativar o registro em log globalmente definindo uma propriedade do sistema -Doracle.jdbc.Trace=true ou pode controlá-la programaticamente usando o Oracle JDBC Diagnosibility MBean.

    

// create name 
javax.management.ObjectName name = new javax.management.ObjectName("com.oracle.jdbc:type=diagnosibility,name=*"); 
// get the MBean server 
javax.management.MBeanServer mbs = java.lang.management.ManagementFactory.getPlatformMBeanServer(); 
// find out if logging is enabled or not 
System.out.println("LoggingEnabled = " + mbs.getAttribute(name, "LoggingEnabled")); 
// enable logging 
mbs.setAttribute(name, new javax.management.Attribute("LoggingEnabled", true)); 
// disable logging 
mbs.setAttribute(name, new javax.management.Attribute("LoggingEnabled", false));

    Apenas ativar o registro em log fornece o mínimo de saída. Para uma saída mais detalhada e direcionada, configure java.util.logging.

  • Como configurar java.util.logging para obter uma saída de rastreamento útil do Oracle JDBC?

    O código JDBC cria vários Loggers. Para obter uma saída interessante, você precisa definir o logLevel em cada um desses Loggers e adicionar um Handler em algum lugar. Consulte JavaDoc para java.util.logging para mais informações.

    Ou você pode usar o arquivo de propriedade conveniente OracleLog.properties fornecido no arquivo demo.zip que faz parte da instalação dos drivers JDBC da Oracle. Os comentários nesse arquivo explicam como usá-lo. Isso é muito mais fácil e altamente recomendado.

    Em ambos os casos, você ainda precisa ativar o registro em log para obter a saída de rastreamento. É possível ativar e desativar a saída de rastreamento sem reconfigurar os Loggers. O MBean de Diagnosticabilidade não se envolve com os Loggers. Se você não quiser alterar sua origem para chamar MBean, pode adicionar -Doracle.jdbc.Trace=true ao comando de execução java. Isso registrará em log a execução inteira.

    Para obter mais informações sobre como configurar o registro em log do JDBC, consulte o artigo técnico sobre registros em log do JDBC. Algumas dicas: definir o Nível como INFO registrará o SQL executado, configurá-lo como FINE registrará a entrada e a saída de todos os métodos públicos e configurá-lo como algo além de FINE preencherá todo o espaço em disco com arquivos de registro em log. Esteja ciente disso.

  • E quanto ao driver Interno do lado do Servidor?

    O driver Interno do lado do Servidor usa java.util.logging para rastrear a saída. Você pode usar o arquivo

    OracleLog.properties conveniente no servidor executando

    System.setProperty("java.util.logging.config.file", "OracleLog.properties")

    Coloque OracleLog.properties em $ORACLE_HOME.