FAQ Oracle JDBC

• Nouveautés de 26ai

  Mis à jour le 3 septembre 2025

  Ce document contient les réponses aux questions les plus fréquentes sur les pilotes JDBC d'Oracle. Notez que cette FAQ traite uniquement de questions techniques spécifiques et sert à documenter les solutions aux questions fréquemment posées par les clients ainsi que les problèmes connus. Pour plus d'informations, consultez le Guide des développeurs JDBC et Javadoc pour JDBC.

  La section ci-dessous présente les principales fonctionnalités JDBC de la version 26ai. Pour plus de détails, reportez-vous à la section Que contient « Oracle DB 26ai Free Developer Release » destinée aux développeurs Java ? et au blog Présentation rapide des nouvelles fonctionnalités d'Oracle JDBC 26ai

  • Dernières normes Java : prend en charge JDK8, JDK11, JDK17, JDK19 et JDK21. Implémente JDBC 4.3 par ojdbc17.jar (à partir de la version 23.6) et compatible avec les API Jakarta. Le fichier ojdbc11.jar est compilé avec JDK11 et implémente JDBC 4.3, le fichier ojdbc8.jar est compilé avec JDK8 implémente JDBC 4.2.Pool de connexions universel (ucp17.jar, ucp11.jar, ucp.jar) pour les applications Java, pilote Oracle R2DBC v1.2.0 implémentant R2DBC SPI, prise en charge de l'image native GraalVM dans le pilote JDBC, threads virtuels (projet Loom) et extension asynchrone au pool de connexions universel.

  • Connexion : prise en charge des fournisseurs de configuration centralisés multicloud (Azure, OCI et WebServer).Prise en charge de l'authentification de jetons OCI IAM, prise en charge de OAUTH2 pour l'authentification de bases de données et l'intégration Azure AD, prise en charge de mots de passe jusqu'à 1024 octets, Easy Connect Plus pour faciliter les connexions TCPS et le transfert des propriétés des connexions, fichier ojdbc.properties pour définir des propriétés des connexions, plusieurs méthodes pour définir TNS_ADMIN, définir le certificat de nom du domaine du serveur (nom de domaine) en tant que propriété des connexions, prise en charge de la nouvelle propriété du portefeuille (my_wallet_directory) et prise en charge de Easy Connect pour LDAPS/LDAP
  • Performances : Prise en charge de Database Pipelining, prise en charge de True Cache, des API JDBC Standard de traitement par lots sont améliorées pour utiliser le pipeline de bases de données sous les couvertures, des extensions réactive JDBC, des extensions réactive UCP, du gestionnaire de connexions Oracle en mode directeur du trafic (CMAN-TDM) et des améliorations apportées aux temps de réponse avec les protocoles executeBatch() et executeLargeBatch(), et de la prise en charge de Bequeath (BEQ).
  • Évolutivité : Prise en charge du Sharding reposant sur une annuaire, de la prise en charge de Raft Replication, de Java Data Source for Shipped Databases Access, de L'affinité des données Oracle RAC pour les transactions XA avec le Sharding Oracle Database, de l'affinité des données Oracle RAC, des API d'acheminement de shards pour les niveau intermédiaires, de la zone de mémoire partagée pour les bases de donnée colocatives et distribuées, et de l'équilibre de charges d'exécution (RLB)
  • Haute disponibilité : migration de sessions avec AC pour les lots et les modèles (c'est-à-dire, attributs stables pouvant faire l' objet d'une restauration), Transparent Application Continuity (TAC), prise en charge des cursiers Session-State-Stable, purge avec lots, prise en charge des classes concrètes dans Application Continuity (AC), AC avec DRCP, prise en charge FAN et Transaction Guard (TG)
  • Sécurité : Prise en charge des mots de pass plus longs (1024bytes), prise en charge des sélections de certifications basées sur l'empreinte digitale, prise en charge des authentifications RADIUS et RADIUS à deux facteurs, connexion rapide pour LDAP/LDAPS, prise en charge des délégations contraintes Kerberos, résolution automatique de fournisseur (OraclePKIProvider), prise en charge des services de fichier de clés (KSS), prise en charge des proxy HTTPS, prise en charge des TLSv1.2 et v1.3, Kerberos, portefeuilles Oracle et JKS
  • Types de données : Recherche vectorielle AI et prise en charge des types de données VECTOR, type de données booléen natif dans oracle.jdbc.OracleType, nouvelles méthodes d'utilitaire (getJsonSchema() et isDualityView()) pour la prise en charge des tableaux associatifs PL/SQL, prise en charge des nouveaux types de données JSON, accès aux tableaux associatifs PL/SQL, paramètre de liaison IN Oracle REF CURSOR.
  • Diagnostic et observabilité : diagnostic autonome (un seul ojdbcX.jar pour la production, le débogage et les mesures), diagnostic lors du premier échec (enregistre l'état d'exécution critique en mémoire et vide l'enregistrement en cas d'erreur).
  • Projets open-source : 
    • Pilote Oracle R2DBC
    • Fournisseurs de configuration/ressources pour OCI, Azure, GCP, AWS et Hashicorp, etc.,
    • Open Telemetry pour l'intégration entre Oracle JDBC et Open Telemetry
    • Oracle Database Operator for Kubernetes v2.0.0
    • Module d'extension IntelliJ Oracle Database Navigator v3.6.1 offrant une suite complète d'outils pour le développement et la gestion de bases de données
    • Pile d'applications pour Java v0.1.0
    • RSI (Reactive Streams Ingest) en mode Streaming et en mode Chargeur de données
    • OCI Toolkit pour Eclipse v1.4.0
    • OCI Toolkit pour IntelliJ v1.2.0
• Existe-t-il des documents relatifs à Oracle Database Cloud Service pour les développeurs Java ?

  Pour les développeurs Java utilisant le pilote JDBC et/ou UCP, les instructions détaillées de connexion au service de base de données sur le cloud sont disponibles sur la page JDBC avec DB Cloud.

• Qu'est-ce que JDBC ?

  L'API JDBC (Java Database Connectivity) est la norme du secteur pour la connectivité indépendante des bases de données entre le langage de programmation Java et un large éventail de bases de données : bases de données SQL et autres sources de données tabulaires, comme des feuilles de calcul ou des fichiers plats. L'API JDBC fournit une API de niveau appel pour l'accès à la base de données SQL.

  La technologie JDBC vous permet d'utiliser le langage de programmation Java afin d'exploiter les fonctionnalités « Write Once, Run Anywhere » pour les applications qui nécessitent un accès aux données d'entreprise. Grâce à un pilote compatible avec la technologie JDBC, vous pouvez connecter toutes les données d'entreprise même dans un environnement hétérogène.

  - Reportez-vous à java.sql pour obtenir un récapitulatif des spécifications JDBC (4.3, 4.2, 4.2, etc.) dans JDK 11.

  - Reportez-vous aux spécifications JDBC complètes à l'adresse jcp.org.

• Où puis-je en savoir plus sur JDBC ?

  Vous pouvez commencer par la page des pilotes JDBC d'Oracle et obtenir plus d'informations à partir du guide des développeurs JDBC et de JDBC Github.

  Il existe beaucoup de livres sur JDBC. JDBC API Tutorial and Reference, Third Edition  est un bon point de départ.

• Où puis-je en savoir plus sur Java ?

  Le site Java d'Oracle est un bon point de départ.

  Il existe beaucoup de livres sur Java. Voici quelques-uns des plus populaires :

  • Java: A Beginner’s Guide (Eighth Edition)
  • Java: The Complete Reference, Eleventh Edition
  • Effective Java Programming Language Guide–2nd Edition

• Quelle version des pilotes JDBC est prise en charge ?

  Reportez-vous au tableau ci-dessous pour connaître les versions prises en charge des pilotes JDBC. Notez que les informations contenues dans ce tableau fournissent un récapitulatif pour plus de commodité. Nous vous recommandons de vous référer à la page 6 sur la Lifetime Support Policy pour plus de détails et pour consulter les mises à jour.

• Qu'est-ce que la matrice d'interopérabilité JDBC et RDBMS ou la matrice de certification ?

  Reportez-vous au tableau qui couvre la matrice d'interopérabilité des pilotes JDBC pour connaître les versions de base de données Oracle prises en charge. Il est recommandé que la version du pilote JDBC soit toujours identique ou supérieure à la version de la base de données Oracle afin de tirer parti des dernières fonctionnalités du pilote.
  

  *Passé : combinaison prise en charge par le passé, mais l'une des versions n'est plus couverte par Premier Assistance, Primary Error Correct Assistance, Extended Assistance et Extended Maintenance Assistance. Les correctifs ne sont plus possibles.

• Quelles sont les versions d'Oracle JDBC par rapport à JDK ?

  Le pilote JDBC Oracle est toujours conforme à la dernière version de JDK dans chacune des nouvelles versions. Dans certaines versions, les pilotes JDBC prennent en charge plusieurs versions de JDK. Utilisez le tableau ci-dessous pour choisir le pilote JDBC approprié en fonction de votre version de JDK préférée.

• Quelles sont les spécifications JDBC par rapport à Oracle JDBC ?

  Le tableau répertorie les pilotes JDBC Oracle et la spécification JDBC prise en charge dans cette version.

• Les pilotes Oracle JDBC sont-ils certifiés pour OpenJDK ?

  Les pilotes Oracle JDBC sont certifiés uniquement pour Oracle JVM (anciennement Sun JVM). Toutefois, les clients utilisent des pilotes Oracle JDBC avec des JVM non Oracle (par exemple, IBM JVM). Il faut toutefois prendre en compte que, pour que l'équipe de développement Oracle JDBC et l'assistance technique Oracle examinent un problème relatif aux pilotes Oracle JDBC, nous exigeons que ce problème soit reproduit sur Oracle JVM.

• Quel est le pilote JDBC 19.x recommandé à utiliser avec JDK11 ?

  La version 19.x comporte
  (a) ojdbc8.jar (compilé avec JDK8 (JDBC 4.2) et peut être utilisée avec JDK9, JDK11) et
  (b) ojdbc10.jar (compilé avec JDK10 (JDBC 4.3) et peut être utilisé avec JDK11).
  Si vous utilisez JDK11, ojdbc8.jar reste un meilleur choix car il inclut toutes les fonctionnalités 4.3, mais sous forme d'extensions Oracle. Les clients peuvent utiliser ojdbc10.jar uniquement s'ils ont besoin de fonctionnalités JDBC 4.3 disponibles via Java SE standard.
  Exemple :
  ojdbc8.jar ::Connection conn = DriverManager.getConnection(. . .);    // conn.beginRequest(); échouerait car beginRequest n'est pas en Java 8  ((OracleConnection)conn).beginRequest(); // réussit car beginRequest est fourni en tant qu'extension 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

• Qu'en est-il de la version JDBC qui ne figure pas dans le tableau ci-dessus ?

  S'il n'est pas répertorié dans le tableau ci-dessus, veuillez consulter votre canal de support pour vérifier si vous bénéficiez toujours du contrat de support pour les versions antérieures.

• Où puis-je obtenir les fichiers jar JDBC ?

  Téléchargez le fichier jar JDBC requis et d'autres fichiers jar complémentaires tels que orai18n.jar, oraclepki.jar, osdt_core.jar, osdt_cert.jar à partir de la page de téléchargement JDBC d'Oracle Technology Network.

• À quoi servent les différents fichiers JAR sur la page de téléchargement du pilote JDBC 19.x ?

  Reportez-vous au tableau ci-dessous pour plus d'informations sur les pilotes JDBC.

  • ojdbc10-full.tar.gz : cette archive contient le dernier pilote léger JDBC 19.x (ojdbc10.jar), le pool de connexions universel (ucp.jar), leurs fichiers Readme et les fichiers jar associés.
  • ojdbc8-full.tar.gz : cette archive contient le dernier pilote léger JDBC 19.x (ojdbc8.jar), le pool de connexions universel (ucp.jar), leurs fichiers Readme et les fichiers jar associés.
  • ojdbc10.jar :: certifié avec JDK11 et JDK10, toutes les classes prenant en charge les fonctionnalités de base pour le pilote léger. Des fichiers jar supplémentaires sont requis lorsque vous utilisez certaines fonctionnalités.
  • ojdbc8.jar :: certifié avec JDK9 et JDK8, toutes les classes prenant en charge les fonctionnalités de base pour le pilote léger. Des fichiers jar supplémentaires sont requis lorsque vous utilisez certaines fonctionnalités.
  • ucp.jar : UCP (Universal Connection Pool), qui fournit les fonctionnalités du pool de connexions.
  • oraclepki.jar, osdt_core.jar et osdt_cert.jar : fichiers JAR supplémentaires requis pour accéder aux portefeuilles Oracle à partir de Java.
  • orai18n.jar : à utiliser par le démon ONS (Oracle Notification Services).
  • simplefan.jar : API Java pour l'abonnement aux événements RAC via ONS
  • xbd6.jar : classes prenant en charge l'interface JDBC 4.x java.sql.SQLXML standard
  • ojdbc8_g.jar : identique à ojdbc8.jar, sauf compilé avec l'option -g pour inclure les informations de débogage et avec les appels java.util.logging inclus.
  • ojdbc8dms.jar : identique à ojdbc8.jar, à l'exception du code qui prend en charge Oracle Dynamic Monitoring Service (DMS). Inclut également une prise en charge de la journalisation JDBC. Ce fichier ne peut être utilisé que lorsque dms.jar se trouve également dans la classpath. Le fichier dms.jar n'est pas fourni avec le produit RDBMS. Il n'est disponible qu'avec le produit Oracle Application Server.
  • ojdbc8_g.jar : identique à ojdbc8.jar mais compilé avec l'option -g pour inclure les informations de débogage et la prise en charge complète de la journalisation JDBC.

• Quels sont les différents pilotes JDBC fournis par Oracle ?

  Oracle fournit quatre types de pilote JDBC différents, à utiliser dans différents scénarios de déploiement. Bien que tous les pilotes JDBC Oracle soient similaires, certaines fonctionnalités s'appliquent uniquement aux pilotes OCI JDBC et certaines s'appliquent uniquement au pilote léger JDBC.

  • Pilote côté client léger JDBC : il s'agit d'un pilote JDBC de type 4 qui utilise Java pour se connecter directement à Oracle. Il implémente les adaptateurs SQL*Net Net8 et TTC d'Oracle à l'aide de sa propre implémentation de socket Java basée sur TCP/IP. Le pilote léger JDBC ne nécessite pas l'installation du logiciel client Oracle, mais nécessite que le serveur soit configuré avec un processus d'écoute TCP/IP. Nous recommandons à tous nos clients d'utiliser le pilote léger JDBC, car la plupart des nouvelles fonctionnalités sont développées uniquement sur le pilote léger JDBC. Étant donné qu'il est entièrement écrit en Java, ce pilote est indépendant de la plate-forme.
  • Pilote léger JDBC côté serveur : il s'agit d'un autre pilote JDBC de type 4 qui utilise Java pour se connecter directement à Oracle. Ce pilote est utilisé en interne dans la base de données Oracle. Ce pilote offre les mêmes fonctionnalités que le pilote léger JDBC côté client (ci-dessus), mais s'exécute dans une base de données Oracle et est utilisé pour accéder aux bases de données distantes. Étant donné qu'il est entièrement écrit en Java, ce pilote est indépendant de la plate-forme.
  • Pilote côté client JDBC OCI (déprécié) :: il s'agit d'un pilote JDBC de type 2 qui utilise des méthodes natives Java pour appeler des points d'entrée dans une bibliothèque C sous-jacente. Cette bibliothèque C, appelée OCI (Oracle Call Interface), interagit avec une base de données Oracle. Le pilote JDBC OCI requiert une installation client Oracle de la même version que le pilote.

    Remarque : Le pilote client Oracle JDBC-OCI ou de type 2 est en phase d'abandon. Reportez-vous à la note MOS 2953282.1 pour l'avis d'abandon.

  • Pilote interne JDBC côté serveur :: il s'agit d'un autre pilote JDBC de type 2 qui utilise des méthodes natives Java pour appeler des points d'entrée dans une bibliothèque C sous-jacente. Cette bibliothèque C fait partie du processus serveur Oracle et communique directement avec le moteur SQL interne dans les appels, évitant ainsi tout trafic réseau. Cela permet à votre code Java exécuté sur le serveur d'accéder plus rapidement à la base de données sous-jacente. Elle peut uniquement être utilisée pour accéder à la même base de données. L'utilisation de méthodes natives rend la plate-forme de pilote interne JDBC côté serveur spécifique. Ce pilote interne côté serveur est entièrement compatible avec les pilotes côté client et prend en charge les mêmes fonctionnalités et extensions.
• Quel pilote dois-je utiliser ?

  Le meilleur choix consiste à utiliser le pilote léger JDBC Oracle. Toutes les nouvelles améliorations et fonctionnalités sont implémentées uniquement sur le pilote fin JDBC.

  Si vous utilisez un réseau non-TCP/IP, vous devez utiliser le pilote OCI.

  Pour un traitement sur place dans votre session de base de données (c'est-à-dire Java dans la base de données), vous devez utiliser le pilote intégré de type 2 (ou le pilote interne du serveur). Si votre code java en cours d'exécution dans votre session doit accéder à une base de données Oracle distante ou à une autre session dans la même instance de base de données, vous devez utiliser le pilote incorporé de type 4 (ou le pilote léger du serveur).

• Qu'en est-il des fichiers jar pour le pilote léger du serveur et le pilote interne du serveur ?

  Ces deux pilotes s'exécutent uniquement dans la machine virtuelle Java du serveur Oracle et leurs classes sont installées dans le cadre de l'installation de la machine virtuelle. Aucun fichier de classes distinct n'est disponible ou nécessaire pour ces pilotes. Consultez les références InternalT2Driver.java et InternalT4Driver.java.

• Les fournisseurs tiers peuvent-ils distribuer les pilotes JDBC d'Oracle avec leurs propres logiciels ?

  Si vous êtes une entreprise logicielle tierce (et partenaire Oracle), consultez la licence FUTC et soumettez-la à votre service juridique, puis contactez votre représentant commercial Oracle local pour plus de détails.

• Quels sont les droits d'accès requis par les pilotes JDBC Oracle ?

  Lorsque votre application est exécutée avec SecurityManager activé (ce qui doit être le cas en production), certaines opérations sont soumises à des privilèges. Pour effectuer ces opérations, le code doit disposer des autorisations appropriées.

  Pour savoir quelles autorisations accorder, consultez le fichier ojdbc.policy sur la page de téléchargement. Il s'agit d'un fichier de stratégie de sécurité générique que vous pouvez utiliser pour accorder aux pilotes tous les droits d'accès nécessaires. Dans la plupart des cas, vous pouvez éliminer un grand nombre de permissions, car votre application n'utilise pas les fonctionnalités qui en ont besoin.

  Ce fichier s'appuie sur un certain nombre de propriétés système. Pour utiliser ce fichier, vous devez définir ces propriétés à l'aide de l'option -D de la commande java.

  Certaines autorisations doivent uniquement être accordées au code du pilote JDBC. Les opérations qui requièrent ces droits d'accès sont incluses dans un bloc doPriviliged. D'autres autorisations doivent également être accordées au code qui appelle les pilotes. Ces opérations ne sont pas incluses dans les blocs doPriviliged. Un exemple notable est que le code appelant a besoin de l'autorisation de socket ouverte lors de l'utilisation du pilote léger pour ouvrir une connexion. Cela permet d'éviter que du code malveillant n'utilise les pilotes pour une attaque entraînant un déni de service, entre autres raisons.

• Comment installer le pilote léger ?

  Téléchargez le pilote JDBC Oracle conforme à la version de JDK que vous utilisez. Vous trouverez les dernières versions du pilote JDBC sur la page de téléchargement. Veillez à inclure les pilotes JDBC sur la classpath. Reportez-vous à la section À quoi servent les différents fichiers jar sur la page de téléchargement ? pour déterminer les fichiers dont vous avez besoin.

• Comment installer le pilote léger ?

  Le pilote JDBC OCI requiert généralement une installation client Oracle de la même version que le pilote. Toutefois, le pilote JDBC OCI est disponible avec la fonctionnalité OCI Instant Client, qui ne nécessite pas une installation complète du client Oracle. Reportez-vous à la documentation sur l'installation d'OCI Instant Client.

• Comment installer le pilote interne côté serveur ou le pilote léger dans le pilote du serveur ?

  C'est inutile. Ces deux pilotes sont installés dans le cadre de l'installation de la base de données. Si la base de données a été installée avec la prise en charge de Java, ces deux pilotes sont déjà installés et disponibles. Reportez-vous à Puis-je charger l'un des fichiers de classes dans la machine virtuelle Java du serveur Oracle ?

• Quelle est la différence entre DriverManager et DataSource ?

  Première version de JDBC indiquée à l'aide de la classe java.sql.DriverManager pour créer des connexions. Cela s'est révélé insuffisant et les versions ultérieures de la spécification JDBC définissent un moyen supplémentaire de créer des connexions à l'aide de DataSources. Nous vous recommandons d'utiliser des DataSources.

  Les DataSources offrent un moyen plus flexible de créer des connexions. Les DataSources ont été conçues pour être utilisées avec JNDI, mais vous n'avez pas besoin d'utiliser JNDI pour utiliser des DataSources. Les DataSources offrent d'autres fonctionnalités que la simple création de nouvelles connexions. En particulier, un DataSource peut implémenter un cache de connexion. Les DataSources sont désormais le moyen préféré de créer une connexion.

  La méthode la plus simple pour obtenir une connexion à partir d'un DataSource est la suivante :

  ds = new oracle.jdbc.pool.OracleDataSource();
  
  ds.setURL(myURL); 
  conn = ds.getConnection(user, password);

• Quel pool de connexions dois-je utiliser ?

  Utilisez Universal Connection Pool (UCP). Ce nouveau mécanisme de mise en cache des connexions est indépendant du pilote, du protocole et de la base de données. Il prend en charge les connexions non JDBC et les connexions JDBC à des bases de données autres qu'Oracle. Lorsque vous utilisez Oracle JDBC, il fournit des fonctionnalités avancées d'Oracle, notamment :

  • attributs de connexion pour entrelacer et réutiliser les connexions
  • un gestionnaire de cache de connexions par machine virtuelle pour gérer un ou plusieurs caches de connexion
  • le délai d'expiration de connexion abandonné pour récupérer les connexions inactives extraites, etc.
  • Équilibrage de la charge de connexion à l'exécution pour allouer du travail aux instances les plus performantes

  Le cache de connexion implicite Oracle n'est plus pris en charge. L'ancien cache de connexion, OracleConnectionCacheImpl, n'était plus pris en charge dans la version 11.1.

• Qu'est-ce que le pool de connexions OCI JDBC ?

  Le pool de connexions OCI JDBC permet de regrouper plusieurs sessions en conservant le statut et avec peu de connexions physiques sous-jacentes à la base de données. La connexion est liée à la session uniquement pendant la durée de l'appel. L'élément de pool est la connexion physique sous-jacente. Les sessions d'application peuvent migrer (internalement) vers n'importe quelle connexion physique disponible sous-jacente.

  Chaque connexion physique du pool dispose d'une session interne supplémentaire au serveur. Vous pouvez donc voir d'autres sessions sur le serveur.

• Quelle est la forme d'une URL ?

  La forme générale d'une URL est

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

  Le <drivertype>

  • thin
  • oci
  • kprb

  Le <username/password> est vide ou au format

  <username>/<password>

  Notez qu'une URL comme

  a un nom utilisateur et un mot de passe vides alors que cette URL

  jdbc:oracle:thin:@mydatabase

  ne spécifie pas de nom utilisateur ni de mot de passe. Lorsque vous utilisez ce formulaire, le nom d'utilisateur et le mot de passe doivent être fournis d'une autre manière.

• Quelle est la forme de la description ?

  La description <database> dépend du type de pilote. Si le type de pilote est kprb, la description <database> est vide. Si le type de pilote est oci et que vous souhaitez utiliser une connexion léguée, <database> est vide. Dans le cas contraire (pilote léger ou oci et non légué), la description de la base de données est l'une des suivantes :

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

  L'URL suivante connecte l'utilisateur scott avec le mot de passe tiger à une base de données avec le service orcl (Important : reportez-vous à plus d'informations sur lse services) via le port 1521 de l'hôte myhost, à l'aide du pilote léger.

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

  Cette URL se connecte à la même base de données à l'aide du pilote OCI et de SID inst1 sans indiquer le nom d'utilisateur ni le mot de passe.

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

  Cette URL se connecte à la base de données nommée GL dans le fichier tnsnames.ora à l'aide du pilote léger et sans qu'il soit nécessaire d'indiquer le nom d'utilisateur ni le mot de passe. Le nom d'utilisateur et le mot de passe doivent être indiqués ailleurs.

  jdbc:oracle:thin:@GL

  La prise en charge des entrées TNSNAMES avec le pilote léger est nouvelle dans la version 10.2.0.1.0. Pour que cela fonctionne, vous devez avoir configuré correctement le fichier tnsnames.ora.

• Comment utiliser l'argument Properties ?

  En plus de l'URL, utilisez un objet de la classe Java Properties standard comme entrée. Par exemple :

  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);

  
  

  Toutes les propriétés prises en charge sont définies dans JavaDoc pour oracle.jdbc.OracleConnection. Des constantes définissent les noms des propriétés. La valeur JavaDoc pour chaque constante décrit le rôle de la propriété et son utilisation.

  Dans les versions antérieures à la version 11.1 du pilote, les propriétés sont définies dans JavaDoc pour oracle.jdbc.pool.OracleDataSource.setConnectionProperties et dans le Guide du développeur Oracle JDBC.

• Ne dois-je pas inscrire la classe OracleDriver auprès de DriverManager ?

  Vous n'avez plus besoin d'enregistrer la classe  OracleDriver pour vous connecter au pilote interne côté serveur, même si cette action n'est pas problématique. Cela s'applique que vous utilisiez getConnection() ou defaultConnection() pour établir la connexion.

  Si vous utilisez ojdbc6.jar et JSE 6 ou une version ultérieure, vous n'avez pas besoin d'enregistrer le pilote, quel que soit celui que vous utilisez. À compter de JSE 6, l'interface de prestation de service Java standard enregistre automatiquement les pilotes. Appelez simplement DriverManager.getConnection . L'exécution trouvera le pilote et l'enregistrera pour vous.

• Quel nom d'utilisateur et quel mot de passe dois-je utiliser pour me connecter au pilote interne du serveur ?

  Tout nom d'utilisateur ou mot de passe que vous incluez dans la chaîne d'URL est ignoré lors de la connexion à la connexion par défaut du serveur. La méthode DriverManager.getConnection()  renvoie un nouvel objet Java Connection  chaque fois que vous l'appelez. Bien que la méthode ne crée pas de connexion à la base de données (une seule connexion implicite est utilisée), elle renvoie un nouvel objet java.sql.Connection.

  Là encore, lorsque le code JDBC est exécuté dans le serveur cible, la connexion est un canal de données implicite, et non une instance de connexion explicite comme elle le serait à partir d'un client. Elle ne doit jamais être fermée.

• Je reçois l'erreur OutofMemory lorsque je définis une valeur de pré-extraction par défaut plus élevée.

  La solution consiste à augmenter la taille de démarrage (-ms) et la taille maximale (-mx) de la base de répartition de mémoire. Ce problème devrait être moins présent avec les pilotes 11.1 et ultérieurs car ils utilisent moins de mémoire que les pilotes 10g. Le livre blanc « Gestion de la mémoire JDBC » contient une discussion plus détaillée sur ce problème, sur la page Web OTN JDBC.

• Qu'est-ce qu'une chaîne de connexion de service ?

  Oracle remplace le mécanisme SID permettant d'identifier les bases de données par une nouvelle approche de services. Ceci est disponible dans la base de données depuis la version 8.1.wi7. JDBC prend en charge les services dans l'URL de connexion. Nous encourageons vivement tous les utilisateurs à passer des SID aux services aussi rapidement que possible, car les SID ne seront plus pris en charge dans l'une des prochaines versions de la base de données.

  Le format de base d'une URL de service est le suivant :

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

  Exemples :

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

  Pour plus d'informations, reportez-vous au Guide d'utilisation JDBC.

• Comment me connecter en tant que SYSDBA ou SYSOPER ?

  La seule façon de procéder est d'utiliser l'objet Propriétés lors de la connexion, plutôt que de spécifier le nom d'utilisateur et le mot de passe en tant que chaînes. Placez le nom d'utilisateur dans la propriété « user » et le mot de passe dans la propriété « password ». Ensuite, placez le mode dans la propriété « internal_logon ». Voici un exemple :

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

  Lors de la connexion en tant que SYSDBA ou SYSOPER à l'aide du pilote léger, le RDBMS doit être configuré pour utiliser un fichier de mots de passe. Reportez-vous à la section« Création et gestion d'un fichier de mots de passe » du « Guide de l'administrateur Oracle Database ».

• Quelles sont les méthodes de cryptage prises en charge par les pilotes JDBC Oracle ?

  Le pilote JDBC OCI prend en charge les mêmes algorithmes que le serveur de base de données.

  Dans les versions 11.1 et 11.2, le pilote léger JDBC prend en charge :

  • RC4_40
  • RC4_56
  • RC4_128
  • RC4_256
  • DES40C
  • DES56C
  • 3DES112
  • 3DES168
  • SSL
  • AES256
  • AES192
  • AES128
• Comment activer le cryptage et la vérification par checksum avec le pilote léger JDBC ?

  En supposant que le serveur soit correctement configuré, utilisez les propriétés de connexion suivantes :

  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");
  

• Qu'est-ce que l'authentification par proxy ?

  L'authentification par proxy permet de se connecter en tant qu'utilisateur via un autre utilisateur. Par exemple, l'authentification par proxy permet au niveau intermédiaire de s'authentifier une fois auprès de la base de données à l'aide d'un compte générique, puis d'établir une session légère pour le compte des utilisateurs réels. Reportez-vous à JavaDoc pour oracle.jdbc.OracleConnection.openProxySession.

• Les pilotes JDBC Oracle prennent-ils en charge le SSL ?

  Oui, mais la prise en charge est propre au pilote. Le chiffrement SSL est pris en charge dans le pilote JDBC-OCI depuis Oracle JDBC 9.2.x et est pris en charge dans le pilote léger depuis la version 10.2.

• Les pilotes JDBC Oracle prennent-ils en charge le protocole LDAP dans l'URL de connexion ?

  Oui. Le pilote léger JDBC prend en charge les protocoles LDAP et LDAP sur SSL standard dans l'URL de connexion, par exemple, lors de l'utilisation d'Oracle Internet Directory en tant que fournisseur LDAP. Pour plus de détails, reportez-vous au Guide du développeur Oracle JDBC et au Guide de l'administrateur Oracle Net Services.

• Comment utiliser JDBC pour me connecter à un serveur de base de données derrière un pare-feu ?

  En règle générale, il est recommandé d'utiliser Oracle Connection Manager pour établir des connexions proxy via le pare-feu. Vous ouvrez un port destiné à être utilisé par Oracle Connection Manager et le laissez gérer le reste des opérations. Vous ne devez ouvrir directement aucun port utilisé par le processus d'écoute de base de données, comme le port 1521.

  Reportez-vous au Guide de l'administrateur Oracle Net Services pour savoir comment configurer Oracle Connection Manager.

Instructions, PreparedStatements, CallableStatements

• Qu'est-ce que defineColumnType et quand devrais-je l'utiliser ?

  defineColumnType est une extension JDBC Oracle qui fournit des performances accrues dans certains cas. Dans les versions antérieures d'Oracle JDBC, tous les pilotes bénéficiaient d'appels à defineColumnType mais à partir de la version 10.1.0, le pilote léger n'a plus besoin des informations fournies. Le pilote léger obtient des performances maximales sans appel à defineColumnType. Les pilotes internes OCI et côté serveur bénéficient toujours de meilleures performances lorsque l'application utilise defineColumnType.

  Si votre code est utilisé avec les pilotes léger et OCI, vous pouvez désactiver la méthode defineColumnType lors de l'utilisation du pilote léger en définissant la propriété de connexion disableDefineColumnType sur "true".  defineColumnType sera ainsi converti en NOOP. Ne définissez pas cette propriété de connexion ou définissez-la sur "false" lors de l'utilisation des pilotes internes OCI ou côté serveur.

  Vous pouvez également utiliser Définir un type de colonne pour modifier le type des données. Vous pouvez également limiter la taille des données de longueur variable.

  Il existe une nouvelle variante de ce paramètre avec un 4ème paramètre pour form_of_use.

• defineColumnType force-t-il les conversions sur le serveur ?

  Non pour le pilote léger et oui pour les pilotes internes OCI et côté serveur.

• Comment désactiver EscapeProcessing au niveau du pilote JDBC plutôt que d'appeler stmt.setEscapeProcessing(false) dans le code d'application ?

  Utilisez une propriété 'CONNECTION_PROPERTY_PROCESS_ESCAPES' dans OracleConnection.

• Les pilotes JDBC Oracle ont-ils fourni une fonction Liaison par nom ?

  Oui. Reportez-vous à JavaDoc pour oracle.jdbc.OraclePreparedStatement. Recherchez les méthodes setXXXAtName.  En outre, oracle.jdbc.OracleCallableStatement prend en charge la liaison d'arguments aux procédures PL/SQL par les noms d'argument formels. Consultez JavaDoc pour connaître les méthodes oracle.jdbc.OracleCallableStatement.setXXX(String, ...). 

  Il est très important de noter que setXXX(String, XXX) se lie à l'aide du nom de paramètre formel de la procédure stockée appelée. setXXXAtName(String, XXX) se lie à l'aide du nom du paramètre de style Oracle (:foo) dans la chaîne SQL en cours d'exécution. Ils sont très différents et peuvent donner des résultats eux aussi très différents.

• Pour les méthodes setXXX dans PreparedStatement, comment les pilotes Oracle JDBC déterminent-ils le type de données ?

  En général, il existe un type de données fixe associé à chaque méthode setXXX, qui est celui qui correspond le plus sensiblement au type de l'argument.

• Que se passe-t-il si le type du paramètre cible est différent du type pris en compte par la méthode setXXX ?

  Les données sont envoyées au serveur au format du type de données supposé et le serveur tente de les convertir en type de paramètre cible. Si aucune conversion n'est possible, le serveur signale une erreur et le pilote génère SQLException au moment de l'exécution.

• Pourquoi les pilotes ne font-ils pas la conversion côté client ?

  Pour les instructions SQL, nous pourrions d'abord accéder au serveur pour obtenir les informations de type, puis effectuer les conversions, mais cela impliquerait des allers-retours supplémentaires. Le code est optimisé pour le cas courant où le programmeur JDBC utilise l'API la plus appropriée pour le type de colonne.

• Pour l'insertion dans une colonne d'une table, quels sont les types de données d'octet ?

  Pour les données d'octet, il existe trois types SQL Oracle : RAW, LONG RAW et BLOB. Les données RAW sont de longueur limitée, stockées directement dans une colonne et transmises au serveur dans des paquets en ligne. Les données LONG RAW ont une limite bien plus importante (2 Go), sont stockées via un mécanisme spécial le long de la ligne et sont transmises au serveur via un mécanisme de rappel en continu. Les données BLOB sont effectivement de longueur illimitée, sont stockées séparément de la table avec seulement un localisateur LOB stocké dans la table. Elles sont transmises au serveur avec des opérations distinctes avant que le localisateur ne soit stocké dans une colonne de la table.

• Pour l'insertion dans une colonne d'une table, quels sont les types de données de caractères ?

  Pour les données d'octet, il existe trois types Oracle SQL : VARCHAR2, LONG et CLOB. Les données VARCHAR2 ont une longueur limitée, sont stockées directement dans une colonne et sont transmises au serveur dans des paquets en ligne. Les données LONG ont une limite bien plus importante (2 Go), sont stockées via un mécanisme spécial le long de la ligne et sont transmises au serveur via un mécanisme de rappel en continu. Les données CLOB sont effectivement de longueur illimitée, sont stockées séparément de la table avec seulement un localisateur LOB stocké dans la table. Elles sont transmises au serveur avec des opérations distinctes avant que le localisateur ne soit stocké dans une colonne de la table.

• Quelles sont les tailles pour setString, setCharacterStream et setAsciiStream, et les limites pour les données binaires via setBytes et setBinaryStream ?

  Reportez-vous au tableau ci-dessous pour les tailles de setString, setCharacterStream et setAsciiStream, ainsi que les limites pour les données binaires via setBytes et setBinaryStream.

  Remarque concernant les données binaires via setBytes et setBinaryStream  :
  

  pourrait être remplacé par

  commencer Insérer dans les valeurs blob_tab (blob_col) (? ); end;

  1. Le pilote interne côté serveur ne peut pas convertir les données pour les paramètres BLOB des états SQL supérieurs à 2 000 octets. Cette limitation n'existe pas pour les instructions PL/SQL. Il peut s'agit d'une solution de contournement dans de nombreux cas, en encapsulant le code SQL dans le code PL/SQL. Par exemple, une chaîne Java insère des valeurs blob_tab (blob_col) (?)
  2. La méthode spécifique Oracle setBytesForBlob peut être utilisée comme solution de contournement.

• Quelles sont les limites de taille pour les méthodes propriétaires setBytesForBlob et setStringForClob dans oracle.jdbc.OraclePreparedStatement ?

  Consultez le tableau ci-dessous pour les limites de taille des méthodes propriétaires setBytesForBlob, setStringForClob dans oracle.jdbc.OraclePreparedStatement.

  Notes : 
  

  1. La méthode spécifique Oracle setStringForClob peut être utilisée comme solution de contournement.
  2. La méthode spécifique Oracle setBytesForBlob peut être utilisée comme solution de contournement.
  
  

  
  

• Le changement de type de liaison force-t-il l'analyse supplémentaire de l'instruction côté serveur ?

  Oui.

• Qu'en est-il des CallableStatements et des procédures avec des paramètres IN OUT ?

  Les types de données des paramètres IN et OUT doivent être identiques. Le changement automatique entraînera des conflits, sauf si le code utilisateur modifie également le type dans registerOutParameter. Une meilleure approche consiste à ne pas utiliser les paramètres IN OUT lorsque cela peut poser problème. Pour ce faire, vous pouvez modifier la procédure d'origine en ajoutant une procédure wrapper ou un bloc PL/SQL qui utilise des paramètres IN et OUT distincts.

• La sélection des procédures PL/SQL polymorphes change-t-elle lorsque le type de liaison change ?

  Oui. Vous pouvez en tirer parti dans votre code PL/SQL.

• Qu'en est-il du code existant ?

  Le code existant continuera à fonctionner correctement. Il y a un changement. Auparavant, si une entrée dépassait les limites de taille de l'API utilisée, un élément SQLException était généré lors de l'appel de l'API setXXX. À présent, l'exception se produira au moment de l'exécution, si elle se produit.

• Dans certains cas, le pilote crée des LOB temporaires. Est-ce qu'il les suit et les libère ?

  Oui. Ils sont libérés après la prochaine exécution de l'instruction ou lorsque celle-ci est fermée.

• Nous utilisons un jeu de caractères de largeur variable tel que UTF8. Le pilote corrige-t-il la longueur d'octet réelle d'une séquence de caractères ?

  Oui. À l'exception de la décision de passer à CLOB pour les plus grandes chaînes, décision prise en tenant compte de la taille maximale.

• Est-ce une bonne idée d'utiliser, par exemple, setString pour une chaîne vraiment énorme ?

  Il n'est probablement pas judicieux de créer cette chaîne vraiment énorme en premier lieu. Reportez-vous à la documentation des fournisseurs de Java Virtual Machine pour connaître les effets des objets très volumineux sur le système de gestion de mémoire Java.

• Les types de colonnes LONG RAW et LONG sont en phase d'abandon. Pourquoi y a-t-il de nouvelles utilisations des API setXXXStream ?

  Les API de flux ne sont pas en phase d'abandon. Elles offrent de meilleures performances pour certaines opérations que celles de l'API LOB et seront conservées.

• Les API LOB sont beaucoup plus flexibles, n'est-ce pas ?

  Absolument ! Les API LOB autorisent l'accès aléatoire à n'importe quelle partie du LOB. Pensez à les utiliser le cas échéant.

• Pourquoi ne puis-je pas créer un PreparedStatement qui effectue select * from tab where id in ( ?, ?, ?, ...) ?

  Le problème est que le RDBMS ne prend pas en charge les paramètres de liaison pour les éléments de la clause IN. Il s'agit d'une limitation de la base de données, et non du pilote.

• Que signifie « Exhausted Resultset: prepare_for_new_get » ?

  Cette erreur se produit si vous essayez d'utiliser un fichier ResultSet après sa fermeture. Elle se produit également si vous fermez l'instruction qui a créé ResultSet.

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

• Pourquoi dois-je fermer ResultSets ?

  • La spécification JDBC initiale exigeait que les connexions, les instructions et les ResultSets soient fermés lorsqu'ils ne sont plus accessibles. Cela nécessite l'utilisation de finaliseurs. Les finaliseurs ont une pénalité de performance tr-s importante pour tous les aspects d'une application exécutée dans une JVM avec des finaliseurs. Sundécourage fortement leur utilisation. La fermeture automatique requiert l'utilisation de finaliseurs qui seraient mauvais pour tous les clients, qu'ils se fient ou non à la fermeture automatique. Ce compromis n'est pas acceptable.

    À notre connaissance, aucun pilote JDBC d'un fournisseur n'implémente ou n'a jamais implémenté une fermeture automatique, exactement pour la raison décrite ci-dessus. Cette exigence a été supprimée des spécifications, bien que certains vestiges de cette formulation apparaissent à quelques endroits. C'est également le cas dans le tutoriel JDBC. Celui-ci, bien qu'étant informatif et utile, n'est pas définitif. Il n'a pas été mis à jour depuis des années. La spécification JDBC 4.0 ne nécessite absolument pas la fermeture automatique.

    ResultSets, Statemnents et Connections emploient tous les ressources côté client et côté serveur. Tant que ces objets sont ouverts, les ressources associées sont allouées. Les ressources sont libérées uniquement lorsque les objets sont fermés. L'échec de la fermeture de ResultSets, des instructions et/ou des connexions entraînera la perte de ressources et une incidence sur les performances de votre application.

    La fermeture d'une connexion ferme toutes les instructions associées. La fermeture d'une instruction ferme tous les éléments ResultSets associés. Par conséquent, si vous utilisez une connexion, vous pouvez simplement la fermer. Toutes les instructions et ResultSets seront fermées. Cette pratique de programmation est acceptable. Il est recommandé de fermer explicitement les instructions et ResultSets dans des blocs finaux. Cela rend votre application plus robuste et moins susceptible de laisser fuir des ressources, au fur et à mesure qu'elle évolue pour répondre à l'évolution des besoins.

    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(); }

  
  

• Que se passe-t-il avec DATE et TIMESTAMP ?

  Cette section concerne les types de données simples. :-)

  Avant la version 9.2, les pilotes JDBC Oracle mettaient en correspondance le type SQL DATE avec java.sql.Timestamp. Cela était assez logique, car le type SQL Oracle DATE contient à la fois des informations de date et d'heure, comme java.sql.Timestamp. La correspondance la plus évidente avec java.sql.Date était quelque peu problématique car java.sql.Date n'inclut pas d'informations temporelles. Il s'avérait également que le RDBMS ne prenne pas en charge le type SQL TIMESTAMP. Il n'y avait donc aucun problème lors de la mise en correspondance de DATE avec Timestamp.

  Dans la version 9.2, la prise en charge de TIMESTAMP a été ajoutée au RDMBS. La différence entre DATE et TIMESTAMP est que TIMESTAMP inclut des nanosecondes, contrairement à DATE. Par conséquent, à partir de la version 9.2, DATE est mis en correspondance avec Date et TIMESTAMP avec Timestamp. Malheureusement, vous ne pouvez pas compter sur les valeurs DATE pour contenir des informations temporelles.

  Il existe plusieurs façons de le résoudre dans les pilotes 9.2 à 10.2 :

  • Modifiez vos tables pour qu'elles utilisent TIMESTAMP au lieu de DATE. C'est sans doute rarement possible, mais c'est la meilleure solution.
  • Modifiez votre application afin qu'elle utilise defineColumnType pour définir les colonnes en tant que TIMESTAMP plutôt que DATE. Cela pose problème car vous ne devez pas utiliser defineColumnType sauf si vous en avez besoin (reportez-vous à Qu'est-ce que defineColumnType et quand dois-je l'utiliser ?).
  • Modifiez l'application pour qu'elle utilise getTimestamp plutôt que getObject. Il s'agit d'une bonne solution lorsque cela est possible, mais de nombreuses applications contiennent du code générique qui repose sur getObject, ce qui ne permet pas toujours de l'appliquer.
  • Définissez la propriété de connexion V8Compatible. Elle indique aux pilotes JDBC d'utiliser l'ancien mappage plutôt que le nouveau. Vous pouvez définir cet indicateur en tant que propriété de connexion ou système. Vous définissez la propriété de connexion en l'ajoutant à l'objet java.util.Properties transmis à DriverManager.getConnection ou à OracleDataSource.setConnectionProperties. Vous définissez la propriété système en incluant une option -D dans la ligne de commande java.java -Doracle.jdbc.V8Compatible="true" MyApp

  Oracle JDBC 11.1 résout ce problème. À partir de cette version, le pilote met en correspondance les colonnes SQL DATE avec java.sql.Timestamp par défaut. Il n'est pas nécessaire de définir V8Compatible pour obtenir le mappage correct. V8Compatible est fortement désapprouvé. Vous ne devez pas du tout l'utiliser. Si vous définissez cette valeur sur true, il n'y aura pas d'impact négatif, mais vous devriez arrêter de l'utiliser.

  Bien qu'il ait été rarement utilisé de cette façon, V8Compatible n'avait pas pour but de résoudre le problème entre DATE et Date, mais de prendre en charge la compatibilité avec les bases de données 8i. Celles-ci (et antérieures) ne prenaient pas en charge le type TIMESTAMP. La définition de V8Compatible a non seulement entraîné la mise en correspondance de SQL DATE avec Timestamp lors de la lecture à partir de la base de données, mais a également entraîné la conversion de tous les éléments Timestamps en SQL DATE lors de leur écriture dans la base de données. Comme 8i n'est pas pris en charge, les pilotes JDBC 11.1 ne prennent pas en charge ce mode de compatibilité. Pour cette raison, V8Compatible n'est plus pris en charge.

  Comme indiqué ci-dessus, les pilotes 11.1 convertissent par défaut SQL DATE en Timestamp lors de la lecture à partir de la base de données. C'était la meilleure solution et le passage à la version 9i a été une erreur. Les pilotes 111 ont rétabli le comportement approprié. Même sans avoir défini V8Compatible dans votre application, vous ne devriez pas voir de différence de comportement dans la plupart des cas. Vous pourriez remarquer une différence si vous utilisez getObject pour lire une colonne DATE. Le résultat sera un Timestamp et non une Date. Etant donné que Timestamp est une sous-classe de Date , il ne s'agit généralement pas d'un problème. Vous pourriez remarquer une différence si vous avez utilisé la conversion de DATE en Date pour tronquer le composant de temps ou si vous utilisez toString sur la valeur. Sinon, le changement doit être transparent.

  Si, pour une raison quelconque, votre application est très sensible à ce changement et que vous devez simplement avoir le comportement 9i-10g, vous pouvez définir une propriété de connexion. Définissez mapDateToTimestamp sur False. Le pilote revient au comportement 9i-10g par défaut et met en correspondance DATE avec Date.

• Quelle est la valeur la plus longue que je puisse lier ?

  Reportez-vous au tableau ci-dessous pour connaître la valeur la plus longue que vous pouvez lier.

  Dans la version 9.2, setString() sur une valeur LONG peut insérer jusqu'à 64 000 caractères avec le pilote OCI et 4 000 avec le pilote léger. Dans la version 10.1.0, nous avons remplacé la limite à 32 000 caractères pour les deux pilotes. Nous savons que la réduction de la limite d'OCI de 64 à 32 000 peut poser problème à certains clients. Cependant, étant donné l'amélioration substantielle des performances rendues possibles par ce changement, et étant donné qu'Oracle recommande vivement à ses clients de migrer de LONG vers CLOB, nous avons décidé que le changement d'architecture était nécessaire.

  Nous recommandons aux clients qui ont besoin de setString() de travailler sur plus de 32 000 caractères pour migrer de LONG vers CLOB.

• Pourquoi le résultat de la lecture d'un TIMESTAMP WITH TIME ZONE est-il différent ?

  L'ancien comportement était incorrect. Consultez le bug 4322830.

  L'ancien comportement consistait à construire un fichier Timestamp qui imprimerait la même valeur que celle de la base de données. Mais comme Timestamp se trouve dans le fuseau horaire UTC, cela donnerait une valeur Timestamp décalée par rapport à la valeur correcte. 8 h 00 le 1er janvier 2007 UTC est différent de 8 h 00 le 1er janvier 2007 PST. Ces heures représentent différents points dans le temps.

  Si vous lisiez 8 h 00 le 1er janvier 2007 PST dans la base de données, les pilotes 9i et 10g construiraient un Timestamp avec la valeur 8 h 00 le 1er janvier 2007 UTC. Cette valeur donnerait une impression «correcte », c'est-à-dire « 8 h 00 1er janvier 2007 », mais elle représente évidemment le mauvais instant dans le temps. Les pilotes 11.1 corrigent ce bug.

• Comment créer des instances d'ADT ?

  JDBC 4.0 a introduit des méthodes d'usine sur l'interface Connection pour la création d'instances d'ADT. Cette API est bien meilleure que l'utilisation de constructeurs. Nous vous encourageons vivement à utiliser les méthodes d'usine autant que possible. Nous n'utiliserons plus les constructeurs très prochainement et nous aimerions les retirer dès que possible.

  Comme les méthodes d'usine standard sont introduites dans JDBC 4.0, ces méthodes sont uniquement disponibles dans les pilotes JSE 6 (ojdbc6.jar). Pour créer des types propriétaires Oracle, les méthodes d'usine sont définies dans OracleConnection pour JSE 5 et JSE 6 (ojdbc5.jar et ojdbc6.jar). Encore une fois, nous vous encourageons vivement à utiliser les méthodes d'usine.

• Pourquoi la méthode de fabrique standard createArrayOf n'est-elle pas prise en charge ?

  Le type de tableau standard SQL est anonyme, c'est-à-dire que le type « array of foo » n'a pas de nom. Seul le type d'élément est nommé. Dans Oracle SQL, le type de tableau est nommé. Les types de baies anonymes ne sont pas pris en charge. Par conséquent, la méthode d'usine standard JDBC 4.0 utilise le type d'élément comme argument et crée une instance de type tableau anonyme. Les pilotes JDBC Oracle définissent une méthode propriétaire Oracle, createArray, qui prend le nom d'un type de tableau et renvoie une instance de ce type de tableau nommé. Cette opération est requise par la définition d'Oracle SQL. À l'heure actuelle, Oracle Database ne prend pas en charge la méthode JDBC 4.0 standard createArrayOf .

• Quelle est la fonction de DBMS_LOB.ERASE ?

  Il "efface" simplement un segment du CLOB. Il ne le raccourcit pas. La longueur du CLOB est donc la même avant et après l'ERASE. Vous pouvez utiliser DBMS_LOB.TRIM pour raccourcir un CLOB.

• Puis-je utiliser oracle.sql.CLOB.putChars() ?

  Oui, mais vous devez vous assurer que les arguments de position et de longueur sont corrects. Vous pouvez également utiliser l'interface OutputStream recommandée qui, à son tour, appelle putChars pour vous.

• OCI fournit une fonction permettant de manipuler un objet CLOB CharSetId. Quel est l'équivalent JDBC ?

  Dans les objets CLOB JDBC, USC2 contient *toujours* le jeu de caractères Oracle correspondant au type « char » Java. Il n'existe donc pas d'équivalent pour le CLOB OCI CharSetId.

• L'écriture dans BLOBS est-elle plus lente que l'insertion de LONG RAW ?

  Cela dépend. Lorsque vous écrivez de petites valeurs, de moins de 10 Ko, les LONG RAW sont plus rapides. Lorsque vous écrivez des valeurs plus volumineuse, la différence s'efface.

• Pourquoi une erreur ORA-03127 s'affiche-t-elle lors de l'obtention de LobLength dans l'exemple de code Stream ?

  Il s'agit du comportement correct. Les colonnes LONG ne sont pas « extraites » sur place (également appelées « in-row »). Elles sont extraites et existent dans le tuyau, jusqu'à ce que vous les lisiez explicitement. Dans ce cas, nous avons obtenu LobLocator (getBlob()), puis nous essayons d'obtenir la longueur de ce LOB avant de lire la colonne LONG. Comme le tuyau n'est pas transparent, nous obtenons l'exception ci-dessus. La solution consiste à lire la colonne Long avant d'effectuer une opération sur le BLOB.

• Lorsque j'obtiens un CLOB à partir de la base de données et que je le mets à jour, certaines modifications n'apparaissent pas dans la base de données. Pourquoi ?

  Les LOB Oracle utilisent la sémantique de valeur. Lorsque vous mettez à jour un LOB, vous devez le réécrire dans la base de données pour être sûr de voir les modifications. Pour des raisons techniques, vos modifications sont parfois enregistrées même si vous n'écrivez pas le LOB, mais vous ne pouvez pas savoir quand. Vous devez donc toujours écrire le LOB.

• Comment transmettre un élément oracle.sql.REF entre deux clients JDBC différents (EJB, clients JDBC, etc.) ? En effet, la classe REF n'est pas sérialisable.

  C'était le cas, mais plus maintenant. REF est maintenant sérialisable.

  La remarque suivante peut encore être utile si vous utilisez une ancienne version des pilotes JDBC Oracle dans lesquels les REF ne sont pas sérialisables.

  Les composants importants de la classe REF sont le tableau d'octets qui représente la référence d'objet et le nom qualifié complet du type d'objet. Vous pouvez utiliser une classe telle que la classe « SomeREF » suivante pour contenir les octets et le nom de type d'un objet REF. Cette classe est sérialisable. Elle peut recréer le REF avec sa méthode « toREF » qui a besoin d'une connexion JDBC en tant que paramètre.

  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); } }

• Comment créer un nouveau REF ?

  • Vous pouvez exécuter des requêtes sur une table contenant des types d'objet REF à Oracle8 et REF sera matérialisé en tant qu'objets Java oracle.sql.REF par JDBC. JDBC ne prend pas en charge la création d'un REF entièrement nouveau. Vous devez accéder à la base de données et insérer le nouveau REF dans SQL. Vous devez ensuite sélectionner le REF et le renvoyer au client.

    Il est plus facile de le faire avec un bloc PL/SQL. Par exemple, si vous avez les tables suivantes :

    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); You can insert a new point value in point_values_table, a new ref to it in the point_ref_table and return the REF to the client with following code: 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);

  
  

• Que sont les types OPAQUE ?

  Les types TOPAQUE ont des données binaires et des méthodes de support qui sont définies dans une bibliothèque de code natif du serveur. Ils ne sont disponibles que pour un usage interne Oracle.

• Lorsque je définis l'attribut de défilement après exécution, il n'a aucun effet sur la défilabilité de RowSet. Pourquoi ?

  Les propriétés d'un bean peuvent être classées comme suit :

  • propriétés de création d'objet
  • propriétés d'exécution

  Les propriétés de création d'objet doivent être définies avant la création de l'objet car il s'agit des propriétés clés pour la création de l'objet. Les propriétés d'exécution peuvent être définies à tout moment et modifient le comportement du bean lors de l'exécution.

  Le défilement, le nom d'utilisateur et le mot de passe sont tous des propriétés de création d'objet. Le statut de validation automatique, le nombre de pré-extraction, etc. sont tous des propriétés d'exécution. En général, l'objet d'arrière-plan prend vie lors de l'exécution/setCommand. Tous les attributs de création d'instructions doivent donc être définis avant cela. Étant donné qu'un objet de connexion est requis pour la création d'une URL d'instruction, un nom d'utilisateur, un mot de passe, etc. requis pour la création d'un élément doivent être définis avant la définition de la commande.

• Puis-je sérialiser l'objet RowSet vers un fichier plat même si RowSet contient des flux ?

  Oui. Les flux sérialisables vous permettent de sérialiser l'objet de flux sur n'importe quel média sérialisable tel qu'un fichier plat, une connexion réseau, etc. Cette fonctionnalité s'applique uniquement à CachedRowSet. Il est possible de créer un fichier CachedRowSet sur un ordinateur où les pilotes JDBC sont présents, puis de le déplacer vers un client distant où seuls les fichiers binaires de rowset sont présents et non les fichiers binaires de pilote. Le client distant peut modifier RowSet en insérant, supprimant ou mettant à jour. Puis, renvoyez-le à l'emplacement où sont présents les pilotes JDBC et les fichiers binaires RowSet pour synchroniser les valeurs modifiées dans la base de données.

• Le pilote léger JDBC peut-il être utilisé pour développer des applications Java ?

  Oui. Le pilote léger JDBC peut être utilisé pour développer des applications Java. Contrairement au pilote OCI JDBC, le pilote léger JDBC fonctionne uniquement avec les réseaux TCP/IP. Les utilisateurs qui exécutent des applications sur des réseaux non-TCP/IP sont encouragés à utiliser le pilote OCI JDBC.

• Quand dois-je utiliser le pilote interne du serveur ?

  Vous devez utiliser le pilote interne du serveur lorsque vous accédez à la base de données dans une procédure stockée Java. Une procédure stockée Java est une méthode Java qui s'exécute dans le RDBMS Oracle, tout comme PL/SQL s'exécute dans le RDBMS. Etant donné qu'il s'exécute dans le RDBMS, il s'exécute nécessairement dans une session de base de données. La connexion au pilote interne du serveur est le descripteur de cette session de base de données. Par conséquent, si votre code est exécuté dans une procédure stockée Java et que vous souhaitez accéder à la base de données, utilisez le pilote interne du serveur, sauf dans les rares cas où vous devez utiliser le pilote léger du serveur.

• Quand dois-je utiliser le pilote léger du serveur ?

  Dans une procédure stockée Java, vous devez généralement utiliser le pilote interne du serveur. Il se connecte à la même session que celle dans laquelle la procédure stockée s'exécute. Toutefois, vous pouvez parfois vous connecter à une autre base de données ou à une nouvelle session dans la même base de données. Dans l'un de ces deux cas, vous devez utiliser le pilote léger du serveur.

• DriverManager.getConnection indique l'erreur : « Aucun pilote approprié »

  Assurez-vous que le pilote est inscrit et que vous utilisez une URL de connexion cohérente avec le pilote JDBC. Pour connaître les valeurs correctes, reportez-vous à Utilisation des pilotes JDBC d'Oracle.

• Message d'erreur : « UnsatisfiedLinkError avec le pilote OCI »

  Lors de l'utilisation de Win NT ou Win95, la machine virtuelle Java indique qu'elle ne peut pas charger OCI73JDBC.DLL lorsque l'une des DLL appelées par OCI73JDBC.DLL ne peut pas être chargée. Les pilotes OCI JDBC utilisent des bibliothèques partagées contenant les parties de code C du pilote. La bibliothèque est OCI73JDBC.DLL pour le programme client Oracle7. La bibliothèque partagée est normalement installée dans [ORACLE_HOME]\BIN lorsque vous installez le pilote JDBC à partir de la distribution. Assurez-vous que le répertoire se trouve dans votre PATH. Pour plus d'informations, reportez-vous à la section Installation de la documentation.

  La bibliothèque partagée dépend également d'autres bibliothèques. Si l'une de ces DLL est manquante, vous obtenez une erreur indiquant que OCI73JDBC.DLL est manquant. JDBC OCI7 requiert les fichiers Oracle7 suivants : CORE35.DLL, CORE35O.DLL, NLSRTL32.DLL et ORA73.DLL

  La machine virtuelle Java (JDK JavaSoft) est JAVAI.DLL.

  L'exécution Microsoft Visual C++ est MSVCRT.DLL, MSVCRTI.DLL, MSVCRT20.DLL et MSVCRT40.DLL.

  Pour trouver la liste des DLL dépendantes, accédez au programme Windows Explorer, cliquez avec le bouton droit de la souris sur la DLL et sélectionnez Quick View. L'écran Quick View affiche, entre autres, la table d'importation qui répertorie les DLL dépendantes. Vous pouvez réinstaller les fichiers de support requis manquants à partir du CD d'installation Oracle. Installez « Required Support Files 7.3.4 », « SQL*Net Client 2.3.4 » et « Oracle TCP/IP Protocol Adapter 2.3.4 »c.

• Message d'erreur : « ORA-1019 : impossible d'allouer de la mémoire ».

  Vous utilisez le pilote OCI8 dans une installation de client Oracle7. Utilisez le pilote OCI7.

• Message d'erreur : « ORA-01000 : maximum de curseurs ouverts dépassé »

  Le nombre de curseurs qu'un client peut ouvrir à la fois sur une connexion est limité (la valeur par défaut est 50). Vous devez fermer explicitement l'instruction à l'aide de la méthode stmt.close() afin de fermer et de libérer les curseurs.

  Si vous ne fermez pas ces curseurs de façon explicite, vous obtiendrez cette erreur. L'augmentation simple de la limite « OPEN_CURSORS » peut vous aider à éviter le problème pendant un certain temps, mais cela masque simplement le problème et ne le résout pas. Vous avez la responsabilité de fermer explicitement les curseurs dont vous n'avez plus besoin.

• Message d'erreur : « ORA-01002 : extraction hors séquence »

  Par défaut, AutoCommit est activé pour une connexion JDBC. Toutefois, pour utiliser une instruction SQL dont la mise à jour est « for update », autoCommit doit être désactivé.

  Par conséquent, la solution consiste à définir autocommit sur false.

• Message d'erreur : « ORA-12705 : valeur de paramètre NLS non valide ou inconnue spécifiée »

  Essayez de définir explicitement NLS_LANG. Si NLS_LANG n'est pas défini ou est défini correctement, vous disposez peut-être d'un client autre que Oracle7.3.4. Installez Oracle7.3.4 sur le client.

• Erreur lors de la tentative de récupération du texte pour l'erreur ORA-12705.

  Il n'y a pas d'installation Oracle sur le client ou l'installation ne s'est pas terminée correctement. Si ce n'est pas déjà fait, utilisez le CD d'installation standard du serveur Oracle et effectuez une installation du client Oracle, pour installer le logiciel nécessaire sur votre ordinateur client. Si vous avez déjà effectué cette opération, vérifiez que l'installation s'est terminée correctement et, si nécessaire, supprimez-la et réinstallez-la.

  Notez que vous pouvez obtenir cette erreur en effectuant une installation client, puis en oubliant de définir ORACLE_HOME. Si vous ne disposez pas de la variable d'environnement ORACLE_HOME, il vous suffit de la définir/de l'exporter pour résoudre le problème, sans avoir à réinstaller le côté client.

• Message d'erreur : le pilote léger JDBC crée des erreurs « caractères non valides » pour les littéraux Unicode

  Le pilote léger JDBC requiert des guillemets autour des littéraux contenant des caractères Unicode. Par exemple :

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

• Les opérations INSERT ou UPDATE sont lentes

  Par défaut, le pilote valide toutes les instructions INSERT et UPDATE dès que vous exécutez l'instruction. Il s'agit du mode autoCommit dans JDBC. Vous pouvez obtenir de meilleures performances en désactivant autoCommit et en utilisant des instructions de validation explicites. Utilisez le point d'entrée setAutoCommit de la classe de connexion pour désactiver autoCommit :

  connection.setAutoCommit(false) : reportez-vous aux mises à jour de traitement par lots dans la documentation JDBC pour plus d'informations sur les extensions Oracle pour la mise en lots des appels vers INSERT et UPDATE. Le traitement par lots de ces commandes peut générer encore plus de rapidité que la désactivation de autoCommit.

• Message d'erreur : « Connexion réinitialisée par le pair »

  En règle générale, cette erreur s'affiche si le serveur s'arrête brutalement lorsque vous y êtes connecté. Vous êtes peut-être en train d'établir une connexion ou passez par une connexion établie. Dans les deux cas, vous devez vérifier les fichiers journaux côté serveur pour voir quelles erreurs et quels vidages de pile ont été générés sur le serveur.

  Notez que cette erreur est différente de ce qui se passe si vous essayez de vous connecter à un port ou même à une machine incorrect/non valide. Vous obtiendrez une erreur différente. Elle diffère également de l'erreur que vous obtenez si le serveur est arrêté et n'accepte pas les demandes de connexion.

• Que signifie « violation de protocole » ?

  Le pilote léger génère cette exception lorsqu'il lit quelque chose du RDBMS qu'il n'attendait pas. Cela signifie que le moteur de protocoles du pilote léger et celui du RDBMS sont désynchronisés. Il n'existe aucun moyen de réparer cette erreur. La connexion est interrompue. Vous devriez essayer de fermer, mais cette action échouera probablement elle aussi.

  Si vous obtenez un cas de test reproductible générant cette erreur, enregistrez un fichier TAR auprès du support technique Oracle. Veillez à indiquer les numéros de version exacts du pilote JDBC et du RDBMS, y compris les patchs.

• Existe-t-il des programmes de démonstration JDBC ?

  Oui. Recherchez dans $ORACLE_HOME/jdbc/demo/demo.tar sur les systèmes UNIX et $ORACLE_HOME/jdbc/demo/demo.zip sur les systèmes Windows.

• Comment exécuter les démos ?

  Décompressez le fichier demo.tar ou demo.zip. Un fichier Samples-Readme.txt s'affiche. Lisez d'abord ce fichier pour un aperçu des démonstrations JDBC, puis exécutez Makefile sous UNIX ou appelez rundemo.bat sous Windows.

• Que dois-je faire si une erreur s'affiche lorsque j'exécute une démonstration ?

  Les démos JDBC devraient s'exécuter sans erreur. Si vous obtenez une erreur, cela signifie probablement qu'il y a un problème dans votre configuration. Vérifiez les points suivants :

  • classpath
  • corriger les versions de jdk
  • Reportez-vous à Samples-Readme.txt, Makefile, et à chaque fichier .java pour connaître les exigences de test préalable.

• Qu'est-ce que JDBC Trace Facility ?

  JDBC Trace Facility est une aide au débogage d'exécution intégrée aux versions précédentes d'Oracle JDBC. Lorsqu'elle est activée, elle imprime les messages relatifs à l'exécution du pilote JDBC Oracle. En règle générale, ces messages incluent l'entrée de méthode, les valeurs de paramètre, l'état interne significatif, les erreurs internes, la sortie de méthode et les valeurs renvoyées.

  À partir de la version 10.1.0, l'utilitaire Oracle Trace n'est pris en charge que dans classes12_g.jar et classes12dms_g.jar. Tous les pilotes JDBC Oracle prenant en charge JDK 1.4 et versions ultérieures utilisent la fonction de trace intégrée dans java.util.logging. Reportez-vous à la section sur java.util.logging pour obtenir des informations de trace lors de l'utilisation de JDBC 11, ojdbc14_g.jar ou ojdbc14dms_g.jar.

  Si vous rencontrez des difficultés avec l'application JDBC, la trace peut s'avérer utile. La plupart des messages concernent les méthodes JDBC internes et peuvent donc être obscurs. Pourtant, vous pourriez recevoir de l'aide. Il est conseillé de définir le volume de trace sur 1 pour commencer.

  Si vous pensez qu'il y a un bug dans JDBC, la trace peut nous aider à vous aider. Dans ce cas, conservez le volume de trace par défaut. En raison du résultat volumineux obtenu, vous devez tracer un petit cas de test ou simplement une partie limitée d'une application plus volumineuse. Assurez-vous d'inclure le code approprié avant la défaillance.

• Comment activer l'ancienne trace JDBC ?

  Reportez-vous à la section sur java.util.logging pour obtenir des informations sur la trace lors de l'utilisation de JDBC 11.

  Pour utiliser JDBC Trace Facility, vous devez utiliser un fichier jar de débogage : classes12_g.jar ou classes12dms_g.jar. Si vous tentez d'utiliser la trace lors de l'utilisation de l'un des autres fichiers JAR ou ZIP, vous obtenez un message d'erreur ou aucun résultat.

  Il existe deux façons de contrôler la trace : de façon programmatique ou via les propriétés. L'API programmatique vous permet d'activer ou de désactiver la trace et de modifier d'autres propriétés pendant l'exécution de votre application. Étant donné le volume souvent élevé de données de trace, il est souvent judicieux de n'activer la trace que pour les bits de code particulièrement suspects. S'il n'est pas facile de modifier la source de l'application, vous pouvez contrôler la trace via les propriétés. Ces propriétés sont lues une seule fois au démarrage de l'application. Vous pouvez utiliser à la fois les propriétés et l'API. Les propriétés définissent l'état initial et l'API le modifie.

  Le moyen le plus simple d'activer la trace par programmation est d'appeler

  oracle.jdbc.driver.OracleLog.startLogging(); Cela envoie la trace à System.out. Pour désactiver l'appel

  oracle.jdbc.driver.OracleLog.stopLogging() ; Vous pouvez également activer la trace en définissant la propriété système oracle.jdbc.Trace sur "true". java -Doracle.jdbc.Trace=true MyApp. La définition de l'une des autres propriétés de JDBC Trace Facility décrites ci-dessous définit implicitement oracle.jdbc.Trace sur "true".

• Comment contrôler le volume de la sortie de trace ?

  Reportez-vous à la section sur java.util.logging pour obtenir des informations sur la trace lors de l'utilisation de JDBC 11.

  JDBC Trace Facility peut produire de nombreux résultats. Le moyen le plus simple de contrôler le volume consiste à n'activer la trace que si nécessaire.

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

  oracle.jdbc.driver.OracleLog.stopLogging(); Souvent, cela n'est pas possible. Vous pouvez également réduire le nombre de messages de trace en définissant le volume de trace. oracle.jdbc.driver.OracleLog.setLogVolume(1); La valeur par défaut est 2. La valeur maximale est 3, mais celle-ci ne produit pas beaucoup plus de 2. 1 est largement inférieur à la valeur par défaut.

  Vous pouvez contrôler la taille de chaque ligne en définissant une taille de ligne explicite ou en modifiant les champs imprimés sur chaque ligne. Pour modifier la longueur de ligne maximale

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

  Pour contrôler quels champs sont imprimés, vous pouvez définir la propriété oracle.jdbc.PrintFields.

  java -Doracle.jdbc.PrintFields=none MyApp Les valeurs valides sont les suivantes :

  • rien, imprime simplement le message
  • par défaut
  • thread, identique à la valeur par défaut plus le nom du thread
  • tout
• Où va la sortie de trace ?

  Reportez-vous à la section sur java.util.logging pour obtenir des informations sur la trace lors de l'utilisation de JDBC 11.

  Par défaut, la sortie de trace va dans System.out. Vous pouvez la rediriger via la propriété oracle.jdbc.LogFile

  java -Doracle.jdbc.LogFile=/tmp/jdbc.log MyApp ou en appelant l'API setLogStream. oracle.jdbc.driver.OracleLog.setLogStream(System.err); La configuration du flux de journal démarre la trace également. Vous pouvez désactiver la trace en définissant le flux de journalisation sur NULL.

• Comment désactiver DMS dans un fichier JAR compatible DMS ?

  Il existe une propriété système oracle.dms.console.DMSConsole. Si cette propriété n'est pas définie, le DMS est actif. S'il est défini sur oracle.dms.instrument_stub.DMSConsole, une implémentation STUB est utilisée, ce qui désactive le DMS. Un moyen de la désactiver pour une application serait d'appeler

  System.setProperty( "oracle.dms.console.DMSConsole", "oracle.dms.instrument_stub.DMSConsole"); avant d'exécuter un code DMS. Vous pouvez également utiliser l'option -D avec la VM Java. java -Doracle.dms.console.DMSConsole=oracle.dms.instrument_stub.DMSConsole MyApp

• Puis-je déboguer des programmes JDBC avec Symantec Visual Cafe ?

  Visual Cafe n'est plus pris en charge.

• Puis-je déboguer des programmes JDBC avec Visual J++ de Microsoft ?

  Visual J++ n'est plus pris en charge.

• Les pilotes JDBC peuvent-ils accéder aux procédures stockées PL/SQL ?

  Oui. Le pilote OCI Oracle JDBC et le pilote léger JDBC prennent tous deux en charge l'exécution des procédures stockées PL/SQL et des blocs anonymes. Ils prennent en charge à la fois la syntaxe d'échappement SQL:2003 et la syntaxe d'échappement Oracle. Les appels PL/SQL suivants sont disponibles à partir des deux pilotes JDBC 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;");
• Les pilotes JDBC prennent-ils en charge la transmission en continu ?

  Oui. Le pilote Oracle JDBC OCI et le pilote léger JDBC prennent tous deux en charge la transmission en continu des données dans les deux sens entre le client et le serveur. Ils prennent en charge toutes les conversions de flux : binaires, ASCII et Unicode. Pour plus d'informations, consultez le tutoriel sur les flux dans la documentation du pilote JDBC Oracle.

• Les pilotes JDBC prennent-ils en charge les jeux de caractères multioctets ?

  Oui. Le pilote Oracle JDBC OCI et le pilote léger JDBC prennent tous deux en charge les jeux de caractères multioctets. Ils peuvent tous deux accéder aux bases de données qui utilisent n'importe quel jeu de caractères Oracle. Ils convertissent les caractères multioctets en Unicode 1.2. Le pilote JDBC OCI a été testé et prend en charge tous les jeux de caractères européens et tous les jeux de caractères asiatiques, y compris le chinois, le japonais et le coréen.

• Les pilotes JDBC fonctionnent-ils avec les pare-feu ?

  Oui. Le pilote OCI JDBC et le pilote léger JDBC peuvent tous deux fonctionner à la fois dans un cadre Intranet et Extranet. Dans un déploiement Extranet, les pilotes peuvent être utilisés avec la plupart des pare-feu de pointe certifiés SQL*Net. Aujourd'hui, les fournisseurs de pare-feu suivants ont certifié leurs pare-feu avec SQL*Net :

  • Pare-feu d'inspection avec conservation de statut : pare-feu à partir du point de reprise, SunSoft et systèmes CISCO.
  • Pare-feux basés sur un proxy : pare-feux de Milkyway Networks, Trusted Information Systems, Raptor, Secure Computing Corporation et Internet mondial.
• Les pilotes JDBC d'Oracle prennent-ils en charge les tables/ensembles de résultats/enregistrements/booléens PL/SQL ?

  Non. Les pilotes JDBC Oracle ne peuvent pas prendre en charge les arguments appelants ou les valeurs renvoyées des types PL/SQL TABLE (désormais appelés tables indexées), RESULT SET, RECORD ou BOOLEAN. Aucune modification sur ce point n'est actuellement prévue. Les utilisateurs sont encouragés à utiliser RefCursor, Oracle Collections et les types d'objet structuré.

  Pour contourner ce problème, vous pouvez créer des procédures wrapper qui gèrent les données en tant que types pris en charge par JDBC.

  Par exemple, pour encapsuler une procédure stockée qui utilise des booléens PL/SQL, vous pouvez créer une procédure stockée qui prend un caractère ou un nombre dans JDBC et la transmet à la procédure d'origine en tant que BOOLEAN, ou, pour un paramètre de sortie, accepte un argument BOOLEAN de la procédure d'origine et le transmet en tant que CHAR ou NUMBER à JDBC. De même, pour encapsuler une procédure stockée qui utilise des enregistrements PL/SQL, vous pouvez créer une procédure stockée qui gère un enregistrement dans ses composants individuels (comme CHAR et NUMBER). Pour encapsuler une procédure stockée utilisant des tables PL/SQL, vous pouvez fractionner les données en composants ou utiliser des types de collecte Oracle.

  Voici un exemple de procédure wrapper PL/SQL MY_PROC pour une procédure stockée PROC qui prend une commande BOOLEAN en entrée :

  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;

• Le basculement est-il pris en charge ?

  Oui. Lors de la connexion à un serveur RAC, la fonction Fast Connection Failover fournit une réponse rapide aux événements d'échec. Cette nouvelle fonctionnalité haute disponibilité est indépendante du pilote et fonctionne conjointement avec le cache de connexion implicite et RAC pour fournir une disponibilité maximale des connexions dans le cache. Pour ce faire, elle traite les événements d'arrêt de RAC afin de supprimer les connexions non valides et les événements d'activité, dans le but d'équilibrer la charge des connexions existantes.

  Si vous utilisez le pilote OCI et que vous avez simplement besoin de basculer des requêtes, vous pouvez opter pour la fonction TAF. Elle facilite principalement le basculement des requêtes dans une application. Il ne s'agit pas d'un mécanisme général de basculement. Notez que les fonctions Fast Connection Failover et TAF ne peuvent pas être utilisées ensemble. Une seule peut être activée et utilisée à la fois.

• Comment les pilotes JDBC prennent-ils en charge les types de données Oracle ROWID ? Quel est le rapport avec getCursorName et setCursorName ?

  Nous ne prenons pas en charge les points d'entrée JDBC getCursorName et setCursorName. Au lieu de cela, nous fournissons l'accès aux ROWID, qui proposent des fonctionnalités similaires. JDBC 4.0 définit java.sql.Rowid qui est entièrement compatible avec oracle.sql.ROWID et est pris en charge dans les pilotes JSE 6 (ojdbc6.jar).

  Si vous ajoutez la pseudo-colonne ROWID à une requête, vous pouvez l'extraire dans JDBC avec le point d'entrée ResultSet getString. Vous pouvez également lier un ROWID à un paramètre preparedStatement avec le point d'entrée setString.

  Cela permet d'effectuer des mises à jour sur place, comme dans l'exemple suivant :

  Dans la classe ResultSetMetaData, les colonnes contenant des ROWID sont signalées avec le type oracle.jdbc.driver.OracleTypes.ROWID, dont la valeur est -8.

• Comment les pilotes JDBC prennent-ils en charge les types de données Oracle REFCURSOR ?

  Le pilote JDBC Oracle prend en charge les variables attachées de type REFCURSOR. Une valeur REFCURSOR est représentée par un élément JDBC ResultSet. Utilisez la méthode getCursor de CallableStatement pour convertir une valeur REFCURSOR renvoyée par un bloc PL/SQL en valeur ResultSet. JDBC permet d'appeler une procédure stockée qui exécute une requête et renvoie un ensemble de résultats. Convertissez CallableStatement en oracle.jdbc.driver.OracleCallableStatement pour utiliser la méthode getCursor.

• ANO fonctionne-t-il avec les pilotes JDBC ?

  À partir de la version 9.2, les pilotes OCI et Thin prennent en charge ANO.

  ANO fonctionne avec les pilotes OCI 8.0.X version 8.0.x et supérieure. Pour que cette fonctionnalité fonctionne correctement, vous devez disposer des derniers ensembles de patches pour les versions 8.0.4, 8.0.5 et 8.0.6.

  Remarque : Il existe un bug connu (#899424) dans les versions 8.1.5 et 8.1.6sdk. Bien que nous ayons publié un correctif, iln'a pas encore été rétroporté et publié en tant que correctif pour toutes les versions précédentes. Jusqu'à présent, ce bug est toujours présent dans les versions 8.1.5 et 8.1.6sdk.

  Le correctif de bug est déjà dans le code 8.1.6. Aucun patch n'est donc nécessaire pour la version 8.1.6 : votre code devrait simplement fonctionner. Pour plus d'informations, reportez-vous au bug n° 899424.

• Puis-je sérialiser les types de données oracle.sql.* ?

  Oui. Toutes les classes oracle.sql.* qui représentent des types de données SQL peuvent être sérialisées.

• Les pilotes JDBC prennent-ils en charge les objets ou les collections ?

  Oui. Les pilotes JDBC Oracle prennent en charge les objets et les collections. C'est le cas depuis la version 8.1.5.

• Puis-je utiliser WaitOption et AutoRollback ?

  Les options d'annulation (rollback) WaitOption et AutoRollback pour la mise en lots des appels sont désapprouvées et ne sont plus disponibles. Vous ne pouvez plus utiliser les méthodes suivantes :

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

• Une procédure stockée Java dans une instance de base de données peut-elle ouvrir une connexion à une autre instance de base de données ?

  Oui, en utilisant le pilote Thin-server. Cette fonction est prise en charge depuis la version 8.1.6sdk.

  La seule solution de contournement connue à ce stade consiste à configurer la première installation pour qu'elle utilise DBLINKS lors de la connexion à la deuxième installation. Cela permet aux pilotes JDBC de penser qu'ils fonctionnent toujours dans la même instance. L'installation s'appuie sur DBLINKS pour les détails. Cependant, des problèmes avec DBLINKS surviennent lors de l'installation d'un serveur MTS.

• Quel est le plus rapide, le pilote léger ou le pilote OCI ?

  Comme toujours, tout dépend de la situation. Il existe des applications où le pilote léger est plus rapide, d'autres où le pilote OCI est plus rapide. À partir de la version 10.1.0, le pilote léger est sans doute un peu plus rapide que le pilote OCI. Dans les cas où le client et le serveur possèdent le même type de matériel et de système d'exploitation, le pilote OCI place un peu moins de charge sur le RDBMS, même si le client léger est plus rapide. Les différences sont généralement faibles, inférieures à 10 %. La plupart de nos clients utilisent le pilote léger en raison de sa facilité d'administration. Votre expérience peut varier.

• Lequel est plus rapide, Statements ou PreparedStatements ?

  Statements peut être légèrement plus rapide si vous n'exécutez le code SQL qu'une seule fois. PreparedStatements est beaucoup plus rapide lorsque le code SQL est exécuté plusieurs fois. Si vous utilisez le cache d'instructions, ce que vous devez faire, l'obtention d'une instruction à partir du cache est identique à l'exécution de la même instruction.

  En général, nous vous recommandons vivement d'utiliser PreparedStatements. Cela est particulièrement vrai si vous envoyez des données fournies par l'utilisateur dans le code SQL. En liant les données à un paramètre PreparedStatement, vous pouvez éviter la plupart des attaques par injection SQL. Tout avantage en termes de performances lié à l'utilisation de Statements est négligeable.

• Comment utiliser java.util.logging pour obtenir la sortie de trace des pilotes JDBC Oracle ?

  Vous devez d'abord utiliser un fichier JAR qui inclut le code de journalisation. Le pilote JDBC ojdbc8.jar n'inclut aucun code de journalisation. Le fichier JAR DMS non débogué, ojdbc8dms.jar, inclut du code de journalisation. Les fichiers JAR de débogage, *_g.jar, incluent un code de journalisation étendu. Assurez-vous qu'il n'existe aucun fichier JAR Oracle JDBC supplémentaire dans votre classpath.

  Ensuite, vous devez activer la journalisation JDBC Oracle. Vous pouvez activer la journalisation globalement en définissant une propriété système -Doracle.jdbc.Trace=true ou vous pouvez la contrôler par programmation à l'aide de Oracle JDBC Diagnosibility MBean.

  // créer un nom
javax.management.ObjectName name = new javax.management.ObjectName("com.oracle.jdbc:type=diagnosibility,name=*") ;
// obtenir le serveur MBean
javax.management.MBeanServer mbs = java.lang.management.ManagementFactory.getPlatformMBeanServer() ;
// déterminer si la journalisation est activée ou non
System.out.println("LoggingEnabled =" + mbs.getAttribute(name, "LoggingEnabled")) ;
// activer la journalisation
mbs.setAttribute(name, new javax.management.Attribute("LoggingEnabled", true)) ;
// désactiver la journalisation
mbs.setAttribute(name, new javax.management.Attribute("LoggingEnabled", false)) ;

  L'activation de la journalisation fournit un résultat minimal. Pour obtenir une sortie plus détaillée et plus ciblée, vous devez configurer java.util.logging.

• Comment configurer java.util.logging pour obtenir une sortie de trace utile à partir d'Oracle JDBC ?

  Le code JDBC crée un certain nombre de journaliseurs. Pour obtenir une sortie intéressante, vous devez définir logLevel sur chacun de ces journaliseurs et ajouter un gestionnaire quelque part. Consultez la JavaDoc relative à java.util.logging pour plus d’informations.

  Vous pouvez également utiliser le fichier de propriétés pratique OracleLog.properties fourni dans le fichier demo.zip qui fait partie de l'installation des pilotes Oracle JDBC. Les commentaires de ce fichier expliquent comment l'utiliser. C'est une solution bien plus facile et fortement recommandée.

  Dans les deux cas, vous devez toujours activer la journalisation pour obtenir la sortie de trace. Vous pouvez activer/désactiver la sortie de trace sans reconfigurer les journaliseurs. Le Diagnosibility MBean ne gêne pas du tout les journaliseurs. Si vous ne souhaitez pas modifier la source pour appeler le MBean, vous pouvez ajouter -Doracle.jdbc.Trace=true à votre commande d'exécution java. Cette opération consigne l'intégralité de l'exécution.

  Pour plus d'informations sur la configuration de la journalisation JDBC, reportez-vous au livre blanc sur la journalisation JDBC. Quelques conseils : définir le niveau sur INFO consignera le code SQL exécuté, le définir sur FINE consignera l'entrée et la sortie de toutes les méthodes publiques, le définir sur une valeur supérieure à FINE remplacera tout votre espace disque par des fichiers journaux. Vous voilà prévenu.

• Qu'en est-il du pilote interne côté serveur ?

  Le pilote interne côté serveur utilise java.util.logging pour le suivi de la sortie. Vous pouvez utiliser le fichier pratique

  OracleLog.properties dans le serveur en exécutant

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

  Placez OracleLog.properties dans $ORACLE_HOME.