Oracle JDBC – Häufig gestellte Fragen (FAQ)

• Neuerungen in 26ai

  Aktualisiert am 3. September 2025

  Dieses Dokument enthält Antworten zu den am häufigsten gestellten Fragen zu den JDBC-Treibern von Oracle. Beachten Sie, dass diese häufig gestellten Fragen nur auf bestimmte technische Fragen eingehen und dazu dienen, Lösungen für häufige Fragen von Kunden sowie bekannte Probleme zu dokumentieren. Gehen Sie das JDBC-Entwicklerhandbuch und Javadoc für JDBC durch, um weitere Informationen zu erhalten.

  Der folgende Abschnitt hebt die wichtigsten JDBC-Funktionen von Version 26ai hervor. Weitere Informationen finden Sie unter Was ist im „Oracle DB 26ai Free Developer Release“ für Java-Entwickler enthalten? und im Blog Kurzer Einblick in die neuen Features von Oracle JDBC 26ai

  • Aktuelle Java-Standards: Unterstützt JDK8, JDK11, JDK17, JDK19 und JDK21. Implementiert JDBC 4.3 durch ojdbc17.jar (ab 23.6) und ist mit den Jakarta-APIs kompatibel. Die ojdbc11.jar wurde mit JDK11 kompiliert und implementiert JDBC 4.3 JDBC 4.3. Die ojdbc8.jar wurde mit JDK 8 kompiliert und implementiert JDBC 4.2. Der Universal Connection Pool (ucp17.jar, ucp11.jar, ucp.jar) für Java-Anwendungen, der Oracle R2DBC-Treiber v1.2.0 mit Implementierung der R2DBC-SPI, die Unterstützung von GraalVM Native Image im JDBC-Treiber, virtuelle Threads (Project Loom) sowie asynchrone Erweiterungen für den Universal Connection Pool.

  • Verbindung: Unterstützung für zentralisierte Multicloud-Konfigurationsprovider (Azure, OCI und WebServer). Unterstützung für die Authentifizierung mit OCI IAM-Tokens, OAUTH2-Unterstützung für die Datenbankauthentifizierung sowie Integration von Azure AD, Unterstützung von Passwörtern mit bis zu 1024 Byte, Easy Connect Plus für einfachere TCPS-Verbindungen und die Übergabe von Verbindungseigenschaften, Verwendung der Datei ojdbc.properties zur Definition von Verbindungseigenschaften, mehrere Optionen zur Festlegung von TNS_ADMIN, Angabe des Domänennamens (DN) des Serverzertifikats als Verbindungseigenschaft, Unterstützung der neuen Wallet-Eigenschaft (my_wallet_directory) sowie Easy Connect-Unterstützung für LDAPS/LDAP.
  • Leistung: Unterstützung von Database Pipelining, Unterstützung von True Cache, Erweiterung der JDBC Standard-Batching-APIs zur internen Nutzung von Database Pipelining, JDBC Reactive Extensions, UCP Reactive Extensions, Oracle Connection Manager (CMAN) im Traffic Director Mode (CMAN-TDM), verbesserte Antwortzeiten bei executeBatch() & executeLargeBatch(), sowie Unterstützung des Bequeath-Protokolls (BEQ).
  • Skalierbarkeit: Unterstützung von verzeichnisbasiertem Sharding, Unterstützung von Raft-Replikation, Java Data Source für den Zugriff auf geshardete Datenbanken, UCP-Unterstützung für XA-Transaktionen mit Oracle Database Sharding, Oracle RAC Data Affinity, Shard-Routing-APIs für Mid-Tier-Anwendungen, Shared Pool für Multitenant- und geshardete Datenbanken sowie Laufzeit-Lastverteilung (Runtime Load Balancing, RLB).
  • High Availability: Session-Migration mit Application Continuity (AC) für Batches und Templates (d. h. stabile, wiederherstellbare Attribute), Transparent Application Continuity (TAC), Unterstützung von Session-State-Stable-Cursor, kontrolliertes „Draining“ bei Batches, Unterstützung konkreter Klassen mit Application Continuity, AC-Unterstützung mit DRCP, FAN-Unterstützung (Fast Application Notification) sowie Transaction Guard (TG).
  • Sicherheit: Unterstützung längerer Passwörter (bis zu 1024 Byte), Unterstützung der Zertifikatsauswahl basierend auf Fingerabdrücken (Thumbprint), Unterstützung von RADIUS und RADIUS-Zwei-Faktor-Authentifizierung, Easy Connect für LDAP/LDAPS, Unterstützung für Kerberos Constrained Delegation, automatische Anbieterauswahl (OraclePKIProvider), Unterstützung des Key Store Service (KSS), HTTPS-Proxy-Unterstützung, Unterstützung von TLSv1.2, Kerberos, Oracle Wallets und JKS.
  • Datentypen: Unterstützung von AI Vector Search und dem VECTOR-Datentyp, nativer Boolean-Datentyp in oracle.jdbc.OracleType, neue Hilfsmethoden (getJsonSchema() und isDualityView()) zur Unterstützung von Duality Views, Unterstützung des neuen JSON-Datentyps, Zugriff auf PL/SQL-assoziative Arrays sowie Unterstützung von Oracle REF CURSOR als IN-Bind-Parameter.
  • Diagnosefähigkeit und Beobachtbarkeit: Selbstgesteuerte Diagnosefunktionen (eine einzelne ojdbcX.jar für Produktion, Debugging und Metriken) sowie Diagnose beim ersten Fehler, bei der der kritische Ausführungszustand im Speicher aufgezeichnet und bei einem Fehler ausgegeben wird.
  • Open Source-Projekte: 
    • Oracle R2DBC-Treiber
    • Konfigurations-/Ressourcenprovider für OCI, Azure, GCP, AWS und Hashicorp usw.
    • Open Telemetry für die Integration zwischen Oracle JDBC und Open Telemetry
    • Oracle Database Operator for Kubernetes v2.0.0
    • Das Oracle Database Navigator IntelliJ Plug-in v3.6.1 bietet eine umfassende Suite von Tools für die Datenbankentwicklung und -verwaltung
    • App Stack for Java v0.1.0
    • Reactive Streams Ingest (RSI) im Streaming-Modus und Data Loader-Modus
    • OCI Toolkit for Eclipse v1.4.0
    • OCI Toolkit for IntelliJ v1.2.0
• Gibt es Dokumente für Java-Entwickler, die sich auf Orace Database Cloud beziehen?

  Java-Entwickler, die einen JDBC-Treiber und/oder UCP verwenden, können eine detaillierte Anleitung zur Verbindung mit dem Datenbankservice in der Cloud auf der Seite JDBC mit DB-Cloud finden.

• Was ist JDBC?

  Die Java Database Connectivity (JDBC)-API stellt den Branchenstandard für die datenbankunabhängige Konnektivität zwischen der Java-Programmiersprache und einer großen Bandbreite von Datenbanken dar – SQL-Datenbanken sowie anderen tabellarischen Datenquellen wie Kalkulationstabellen oder Flat Files. Die JDBC-API bietet eine aufrufspezifische API für den SQL-basierten Datenbankzugriff.

  Die JDBC-Technologie ermöglicht Ihnen, die „Einmal schreiben, überall ausführen“-Funktionalität der Java-Programmiersprache bei Anwendungen auszunutzen, die einen Zugriff auf Unternehmensdaten erfordern. Mit einem auf die JDBC-Technologie ausgelegten Treiber können Sie selbst in einer heterogenen Umgebung alle Unternehmensdaten vernetzen.

  – Unter java.sql finden Sie eine Zusammenfassung verschiedener JDBC-Spezifikationen (4.3, 4.2, 4.2 usw.,) in JDK 11

  – Die vollständigen JDBC-Spezifikationen finden Sie unter jcp.org

• Wo kann ich mehr über JDBC erfahren?

  Sie können mit der  Seite zu JDBC-Treibern von Oracle beginnen und weitere Informationen im JDBC Developer's Guide und JDBC Github finden.

  Es gibt zahlreiche Bücher zu JDBC. Ein guter Einstieg ist JDBC-API-Tutorial und -Referenz, dritte Auflage .

• Wo kann ich mehr über Java erfahren?

  Ein guter Anfang ist die Java-Seite von Oracle.

  Außerdem gibt es zahlreiche Bücher zu Java. Einige besonders beliebte davon sind:

  • Java: Ein Einsteigerhandbuch (Achte Auflage)
  • Java: Die vollständige Referenz, elfte Auflage
  • Effektive Anleitung zur Programmiersprache Java – 2. Auflage

• Welche Versionen der JBDC-Treiber werden unterstützt?

  Ziehen Sie bitte bezüglich der unterstützten Versionen von JBDC-Treibern die untenstehende Tabelle zu Rate. Beachten Sie bitte, dass die Daten in dieser Tabelle als praktische Zusammenfassung für Sie gedacht sind. Wir empfehlen, für weitere Informationen und mögliche Updates auf Seite 6 der Lifetime Support-Richtlinie nachzusehen.

• Was ist die JDBC- und RDBMS-Interoperabilitätsmatrix oder die Zertifizierungsmatrix?

  Ziehen Sie bitte die Tabelle zur JDBC-Treiberinteroperabilitätsmatrix für die unterstützten Versionen der Datenbanken von Oracle zu Rate. Wir empfehlen, dass die JDBC-Treiberversion immer mindestens genau so hoch sein sollte wie die Version der Datenbank von Oracle, damit die neuesten Funktionalitäten des Treibers genutzt werden können.
  

  *Vorher: War eine unterstützte Kombination, aber eines der Releases wird nicht mehr durch Premier Support, Primary Error Correction Support, Extended Support oder Extended Maintenance Support abgedeckt. Fixes sind nicht mehr möglich.

• Was sind die Versionen von Oracle JDBC in Bezug auf die JDK-Versionen?

  Der Oracle JDBC-Treiber ist bei jeder der jeweiligen neuen Versionen immer mit der aktuellen Version des JDK kompatibel. Bei einigen Versionen unterstützen die JDBC-Treiber mehrere JDK-Versionen. Verwenden Sie die untenstehende Tabelle, um auf der Grundlage Ihrer bevorzugten JDK-Version den korrekten JDBC-Treiber auszuwählen.

• Welche JBDC-Spezifikationen werden von den jeweiligen Oracle JDBC-Versionen unterstützt?

  Die Tabelle führt die Oracle JDBC-Treiber auf und welche JBDC-Spezifikationen in dieser bestimmten Version unterstützt werden.

• Sind die Oracle JDBC-Treiber für OpenJDK zertifiziert?

  Oracle JDBC-Treiber sind nur für Oracle JVM (ehemals Sun JVM) zertifiziert. Allerdings haben Kunden Oracle JDBC-Treiber mit Nicht-Oracle-JVMs (z. B. IBM JVM) verwendet. Die einzige Einschränkung besteht darin, dass wir für die Prüfung eines Problems im Zusammenhang mit Oracle JDBC-Treibern durch das Oracle JDBC-Entwicklungsteam und den Oracle Support verlangen, dass dieses Problem auf der Oracle JVM reproduziert wird.

• Welcher 19.x JDBC-Treiber wird zur Verwendung mit JDK11 empfohlen?

  Version 19.x hat
  (a) ojdbc8.jar (kompiliert mit JDK8 (JDBC 4.2) und kann mit JDK9, JDK11 verwendet werden) sowie
  (b) ojdbc10.jar (kompiliert mit JDK10 (JDBC 4.3) und kann mit JDK11 verwendet werden).
  Falls Sie JDK11 verwenden, dann ist ojdbc8.jar jedoch eine bessere Option, da es alle 4.3-Funktionen enthält, diese jedoch als Oracle-Erweiterungen. Kunden können aber auch nur ojdbc10.jar verwenden, falls sie JDBC 4.3-Funktionen benötigen, die über die Standard-Java SE verfügbar sind.
  Beispiel:
  ojdbc8.jar:Connection conn = DriverManager.getConnection(. . .);    // conn.beginRequest(); würde nicht funktionieren, da beginRequest nicht in Java 8 enthalten ist  ((OracleConnection)conn).beginRequest(); // funktioniert, da beginRequest als Oracle-Erweiterung bereitgestellt wird

  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

• Was ist mit einer JDBC-Version, die nicht in der obenstehenden Tabelle aufgeführt ist?

  Falls eine Version nicht in der obigen Tabelle aufgeführt ist, fragen Sie bitte über Ihren Supportkanal nach, ob Sie immer noch über einen gültigen Supportvertrag für diese ältere Version verfügen.

• Wo finde ich die JDBC-JAR-Dateien?

  Laden Sie bitte die erforderliche JDBC-JAR und andere zugehörige JARs wie orai18n.jar, oraclepki.jar, osdt_core.jar, osdt_cert.jar der JDBC Download-Seite des Oracle Technology Network herunter.

• Wozu dienen die verschiedenen JAR-Dateien auf der Downloadseite des 19.x JDBC-Treibers?

  Ziehen Sie bitte die untenstehende Tabelle zu Rate, um weitere Einzelheiten zu den JDBC-Treibern zu erfahren.

  • ojdbc10-full.tar.gz: Dieses Archiv enthält die neuesten 19.x JDBC-Thin-Treiber (ojdbc10.jar), den Universal Connection Pool (ucp.jar), ihre Readme-Dateien und zugehörige JARs.
  • ojdbc8-full.tar.gz: Dieses Archiv enthält die neuesten 19.x JDBC-Thin-Treiber (ojdbc8.jar), den Universal Connection Pool (ucp.jar), ihre Readme-Dateien und zugehörige JARs.
  • ojdbc10.jar: Zertifiziert mit JDK11 and JDK10, sämtliche Klassen, um grundlegende Funktionalitäten für den Thin-Treiber zu unterstützen. Für die Verwendung einiger Funktionen sind zusätzliche JAR-Dateien erforderlich
  • ojdbc8.jar: Zertifiziert mit JDK9 and JDK8, sämtliche Klassen, um grundlegende Funktionalitäten für den Thin-Treiber zu unterstützen. Für die Verwendung einiger Funktionen sind zusätzliche JAR-Dateien erforderlich
  • ucp.jar: Universal Connection Pool(UCP), der Verbindungspoolfunktionen bereitstellt.
  • oraclepki.jar, osdt_core.jar und osdt_cert.jar: Zusätzliche JAR, die erforderlich ist, um von Java auf Oracle Wallets zugreifen zu können
  • orai18n.jar: Zur Verwendung durch den Oracle Notification Services (ONS)-Daemon
  • simplefan.jar: Java-APIs zum Abonnieren von RAC-Ereignissen über ONS
  • xbd6.jar: Klassen zur Unterstützung der Standard-JDBC 4.x java.sql.SQLXML-Schnittstelle
  • ojdbc8_g.jar: Dasselbe wie ojdbc8.jar außer, dass dieses mit der Option -G kompiliert wurde, sodass Debugging-Daten enthalten sind. Außerdem sind java.util.logging-Aufrufe enthalten.
  • ojdbc8dms.jar: Dasselbe wie ojdbc8.jar außer, dass Code zur Unterstützung von Oracle Dynamic Monitoring Service (DMS) enthalten ist. Außerdem ist einige Unterstützung für das JDBC-Logging enthalten. Diese Datei kann nur verwendet werden, wenn dms.jar sich ebenfalls im Classpath befindet. Die Datei dms.jar wird nicht als Teil des RDBMS-Produkts bereitgestellt. Sie ist nur als Teil des Oracle Application Server-Produkts verfügbar.
  • ojdbc8dms_g.jar: Dasselbe wie  ojdbc8dms.jar außer, dass diese mit der Option -G kompiliert wurde, sodass sie Debugging-Daten und eine vollständige Unterstützung von JDBC-Logging beinhaltet.

• Welche verschiedenen JDBC-Treiber stellt Oracle zur Verfügung?

  Oracle bietet vier verschiedene Arten von JDBC-Treibern an, die in verschiedenen Bereitstellungsszenarien verwendet werden können. Auch wenn alle Oracle JDBC-Treiber ähnlich sind, sind einige Funktionen nur bei JDBC-OCI-Treibern und andere nur beim JDBC-Thin-Treiber anwendbar.

  • Clientseitiger JDBC-Thin-Treiber: Hier handelt es sich um einen JDBC-Treiber vom Typ 4, der Java nutzt, um sich direkt mit Oracle zu verbinden. Er implementiert SQL*Net Net8 und TTC-Adapter von Oracle und nutzt dabei seine eigene TCP/IP-basierte Java-Socket-Implementierung. Der JDBC-Thin-Treiber benötigt zur Installation keine Clientsoftware von Oracle, aber er erfordert, dass der Server mit einem TCP/IP-Listener konfiguriert ist. Wir empfehlen allen unseren Kunden, den JDBC-Thin-Treiber zu verwenden, da die meisten neuen Funktionen nur auf dem JDBC-Thin-Treiber entwickelt werden. Da dieser Treiber vollständig in Java geschrieben ist, ist er plattformunabhängig.
  • Serverseitiger JDBC-Thin-Treiber: Dabei handelt es sich um einen anderen JDBC-Treiber vom Typ 4, der Java nutzt, um sich direkt mit Oracle zu verbinden. Dieser Treiber wird intern in der Datenbank von Oracle verwendet. Dieser Treiber bietet dieselbe Funktionalität wie der clientseitige JDBC-Thin-Treiber (oben), wird aber in der Datenbank von Oracle ausgeführt und für den Zugriff auf Remote-Datenbanken verwendet. Da dieser Treiber vollständig in Java geschrieben ist, ist er plattformunabhängig.
  • Clientseitiger JDBC-OCI-Treiber (veraltet): Hierbei handelt es sich um einen JDBC-Treiber vom Typ 2, der Java-native Methoden verwendet, um Einstiegspunkte in einer zugrunde liegenden C-Library aufzurufen. Diese C-Library, genannt OCI (Oracle Call Interface) interagiert mit einer Datenbank von Oracle. Der JDBC-OCI-Treiber erfordert eine Oracle-Clientinstallation mit derselben Version wie der Treiber.

    Hinweis: Der Oracle JDBC-OCI-Treiber bzw. der JDBC-Typ-2-Clienttreiber ist veraltet. Weitere Informationen zur Abkündigung finden Sie im MOS-Hinweis 2953282.1.

  • Serverseitiger, interner JDBC-Treiber: Hierbei handelt es sich um einen weiteren JDBC-Treiber vom Typ 2, der Java-native Methoden nutzt, um Einstiegspunkte in eine zugrundeliegende C-Library aufzurufen. Die C-Library ist Teil des Oracle-Serverprozesses und kommuniziert innerhalb von Aufrufen direkt mit der internen SQL-Engine , sodass jeglicher Netzwerk-Traffic vermieden wird. Dadurch kann Ihr Java-Code im Server ausgeführt werden, um auf die zugrundeliegende Datenbank auf die schnellstmögliche Weise zuzugreifen. Sie kann nur für den Zugriff auf dieselbe Datenbank verwendet werden. Aufgrund der Verwendung nativer Methoden ist der serverseitige interne JDBC-Treiber plattformspezifisch. Dieser serverseitige interne Treiber ist vollständig mit den clientseitigen Treibern konsistent und unterstützt dieselben Funktionen und Erweiterungen.
• Welchen Treiber sollte ich verwenden?

  Die beste Option ist der Oracle JDBC-Thin-Treiber. Nur auf dem JDBC-Thin-Treiber sind alle neuen Verbesserungen und Funktionen implementiert.

  Falls Sie ein Nicht-TCP/IP-Netzwerk nutzen, müssen Sie den OCI-Treiber verwenden.

  Für die In-Place-Verarbeitung während Ihrer Datenbanksitzung (z.B. Java in der Datenbank) müssten Sie entweder den integrierten Treiber vom Typ 2 (oder den serverinternen Treiber) verwenden. Wenn der Java-Code, der während Ihrer Sitzung ausgeführt wird, auf eine Remote-Datenbank von Oracle oder eine andere Sitzung innerhalb derselben Datenbank-Instanz zugreifen muss, müssen Sie den integrierten Treiber vom Typ 4 (oder Server-Thin-Treiber) verwenden.

• Wie sieht es mit den JARs für den Server-Thin-Treiber und dem serverinternen Treiber aus?

  Diese beiden Treiber können nur in der Oracle Server Java VM ausgeführt werden und ihre Klassen werden zusammen mit der VM installiert. Für diese Treiber sind keine getrennten Klassendateien verfügbar oder notwendig. Weitere Informationen finden Sie unterInternalT2Driver.java und InternalT4Driver.java.

• Können Drittanbieter die JDBC-Treiber von Oracle zusammen mit ihrer eigenen Software vertreiben?

  Falls Sie ein Drittanbieter-Softwareunternehmen (Oracle Partner) sind, lesen Sie bitte die FUTC-Lizenz, lassen Sie diese durch Ihre Rechtsabteilung prüfen und kontaktieren Sie dann Ihren Oracle-Vertriebsmitarbeiter vor Ort, um weitere Einzelheiten zu erfragen.

• Welche Genehmigungen erfordern die Oracle JDBC-Treiber?

  Wenn Ihre Anwendung mit einem aktivierten SecurityManager ausgeführt wird (wie es während der Produktion der Fall sein sollte), sind bestimmte Abläufe privilegiert. Um diese Abläufe ausführen zu können, müssen dem Code die entsprechenden Berechtigungen erteilt werden.

  Sie können in der Datei ojdbc.policy auf der Downloadseite erfahren, welche Berechtigungen erteilt werden müssen. Dabei handelt es sich um eine generische Sicherheitsrichtlinien-Datei, die Sie verwenden können, um Treibern alle notwendigen Berechtigungen zu erteilen. In den meisten Fällen sollten Sie zahlreiche Berechtigungen als Kommentare markieren, da Ihre App die Funktionen, welche diese Berechtigungen erfordern, nicht verwendet.

  Diese Datei hängt von einer Reihe von Systemeigenschaften ab. Um diese Datei verwenden zu können, müssen Sie diese Eigenschaften mit der Option -D für den Befehl Java definieren.

  Einige der Berechtigungen müssen nur dem JDBC-Treibercode erteilt werden. Die Abläufe, welche diese Berechtigungen erfordern, sind in einem doPriviliged-Block eingeschlossen. Weitere Berechtigungen müssen auch dem Code erteilt werden, der die Treiber aufruft. Diese Abläufe sind nicht in doPriviliged-Blöcken eingeschlossen. Ein beachtenswertes Beispiel ist, dass der aufrufende Code die Berechtigung zum Öffnen des Sockets benötigt, wenn über den Thin-Treiber eine Verbindung geöffnet wird. Dadurch wird, unter anderem, verhindert, dass gefährlicher Code die Treiber für Denial-of-Service-Angriffe nutzt.

• Wie installiere ich den Thin-Treiber?

  Laden Sie den Oracle JDBC-Treiber herunter, der mit der von Ihnen verwendeten JDK-Version kompatibel ist. Sie können die neuesten Versionen des JDBC-Treibers auf der Downloadseite. finden. Stellen Sie sicher, dass Sie die JDBC-Treiber auf dem Classpath miteinschließen. Sehen Sie sich Wozu dienen die verschiedenen JAR-Dateien auf der Downloadseite? an, um zu bestimmen, welche Dateien Sie benötigen.

• Wie installiere ich den OCI-Treiber?

  Der JDBC-OCI-Treiber erfordert im Allgemeinen eine Oracle-Client-Installation mit derselben Version wie der Treiber. Dieser JDBC-OCI-Treiber ist allerdings mit der OCI Instant Client-Funktion verfügbar, die keine komplette Installation des Oracle-Client erfordert. Weitere Informationen finden Sie in der Dokumentation zur Installation von OCI Instant Client.

• Wie installiere ich die serverseitigen internen Treiber oder den Thin-Treiber im Servertreiber?

  Gar nicht. Diese beiden Treiber werden bereits zusammen mit der Datenbank installiert. Wenn die Datenbank mit Java-Unterstützung installiert wurde, sind diese beiden Treiber bereits ebenfalls installiert und verfügbar. Siehe Kann ich eine der Klassendateien in die Oracle Server Java VM laden?

• Was ist der Unterschied zwischen DriverManager und DataSources?

  Bei der ersten Version von JDBC wurde spezifiziert, dass die Klasse java.sql.DriverManager zum Erstellen von Verbindungen verwendet wird. Dies erwies sich aber als nicht ausreichend flexibel und spätere Versionen der JDBC-Spezifikationen definieren eine zusätzliche Möglichkeit, Verbindungen mithilfe von DataSources herzustellen. Wir empfehlen Ihnen die Verwendung von DataSources.

  DataSources bieten Ihnen eine flexiblere Möglichkeit zum Erstellen von Verbindungen. DataSources wurden darauf ausgelegt, mit JNDI verwendet zu werden, aber Sie müssen JNDI nicht verwenden, um DataSources nutzen zu können. DataSources können auch noch andere Dinge tun, als nur neue Verbindungen zu erstellen. Insbesondere kann eine DataSource einen Verbindungscache implementieren. DataSources sind nun die bevorzugte Methode zum Erstellen von Verbindungen.

  Die einfachste Möglichkeit, von einer DataSource eine Verbindung zu erhalten, ist:

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

• Welchen Verbindungspool sollte ich verwenden?

  Sie sollten Universal Connection Pool (UCP) verwenden. Dieser neue Mechanismus für das Verbindungs-Caching ist unabhängig von Treibern, Protokollen und Datenbanken. Er unterstützt sowohl Nicht-JDBC- wie JDBC-Verbindungen zu Datenbanken anderer Anbieter als Oracle. Bei der Verwendung von Oracle JDBC stellt er fortgeschrittene Oracle-Features bereit wie etwa:

  • Verbindungsattribute für Stripe und die Wiederverwendung von Verbindungen
  • einen Verbindungs-Cache Manager pro VM zur Verwaltung von einem oder mehreren Verbindungscaches
  • einen Timeout für abgebrochene Verbindungen, nicht genutzte ausgecheckte Verbindungen zurückzufordern usw.
  • Runtime Connection Load Balancing, um Aufgaben den Instanzen mit der besten Performance zuzuweisen

  Der Oracle Implicit Connection Cache wird nicht weiter unterstützt. Beachten Sie, dass der alte Verbindungscache OracleConnectionCacheImpl ab Version 11.1 nicht mehr unterstützt wird.

• Worum handelt es sich bei JDBC OCI Connection Pooling?

  JDBC OCIConnectionPool dient dem Zusammenfassen mehrerer Stateful Sessions mit wenigen zugrundeliegenden physischen Verbindungen zur Datenbank. Die Verbindung ist nur für die Dauer des Aufrufs an die Session gebunden. Das Pool-Element ist die zugrundeliegende physische Verbindung. Die Anwendungs-Sessions können (intern) zu jeder zugrundeliegenden verfügbaren physischen Verbindung migrieren.

  Jede physische Verbindung vom Pool verfügt über eine zusätzliche interne Verbindung zum Server. Daher werden auf dem Server noch weitere Verbindungen angezeigt.

• Welche Form hat eine URL?

  Die allgemeine Form einer URL ist

  jdbc:oracle:<drivertype>:<benutzername/kennwort>@<database>

  Der <treibertyp>

  • thin
  • oci
  • kprb

  <benutzername/kennwort> ist entweder leer oder hat die Form

  <benutzername>/<kennwort>

  Beachten Sie, dass eine URL wie

  einen leeren Benutzernamen und ein leeres Kennwort aufweist, während diese URL

  jdbc:oracle:thin:@mydatabase

  weder einen Benutzernamen noch ein Kennwort spezifiziert. Bei Verwendung dieser Form müssen Benutzername und Kennwort auf andere Weise angegeben werden.

• Was ist die Form der Beschreibung?

  Die <datenbank> beschreibung hängt etwas vom Treibertyp ab. Falls der Treiber vom Typ kprb ist, ist die <datenbank> beschreibung leer. Falls der Treiber vom Typ oci ist, und Sie eine Bequeath-Verbindung verwenden möchten, ist die <datenbank> leer. Andernfalls ( thin- oder oci-Treiber und nicht bequeath) ist die Datenbankbeschreibung wie folgt:

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

  Die folgende URL verbindet den Benutzer scott mit dem Kennwort tiger zu einer Datenbank mit dem Service orcl (Wichtig: mehr zu Services anzeigen) über Port 1521 des Hosts myhost, wobei der Thin-Driver verwendet wird.

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

  Diese URL stellt eine Verbindung zur selben Datenbank mit dem OCI-Treiber und der SID inst1 her, ohne dabei Benutzername oder Kennwort zu spezifizieren.

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

  Diese URL stellt eine Verbindung zur Datenbank namens GL in der tnsnames.ora-Datei her, wobei der Thin-Treiber verwendet und kein Benutzername oder Kennwort spezifiziert wird. Der Benutzername und das Kennwort müssen dabei an anderer Stelle angegeben werden.

  jdbc:oracle:thin:@GL

  Die Unterstützung von TNSNAMES-Einträgen beim Thin-Treiber ist bei der Version 10.2.0.1.0 neu hinzugefügt worden. Damit dies funktioniert, müssen Sie die Datei tnsnames.ora richtig konfiguriert haben

• Wie verwende ich das Properties-Argument?

  Verwenden Sie dazu zusätzlich zur URL ein Objekt der Java-Standardklasse Properties als Eingabe. Zum Beispiel:

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

  
  

  Alle unterstützten Eigenschaften sind im JavaDoc für oracle.jdbc.OracleConnection definiert. Es gibt Konstanten, welche die Eigenschaftsnamen definieren. Das JavaDoc für die jeweilige Konstante beschreibt, was die Eigenschaft tut und wie sie verwendet wird.

  In Versionen des Treibers niedriger als11.1 sind die Eigenschaften im JavaDoc für oracle.jdbc.pool.OracleDataSource.setConnectionProperties and im Oracle JDBC Developer's Guide definiert.

• Muss ich die Klasse beim DriverManager registrieren?

  Es ist nicht länger erforderlich, die OracleDriver-Klasse zu registrieren, um eine Verbindung zum serverseitigen internen Treiber herzustellen, auch wenn dies nicht schaden kann. Dies gilt unabhängig davon, ob Sie getConnection() oder defaultConnection() verwenden, um die Verbindung zu erstellen.

  Falls Sie ojdbc6.jar und JSE 6 oder spätere Versionen verwenden, müssen Sie den Treiber überhaupt nicht mehr registrieren, unabhängig davon, welchen Treiber Sie verwenden. Ab JSE 6 registriert das Standard-Java Service Provider Interface die Treiber automatisch. Rufen Sie einfach DriverManager.getConnection auf und die Laufzeit findet den Treiber und registriert ihn für Sie.

• Welchen Benutzernamen und welches Kennwort sollte ich bei der Verbindung mit dem internen Servertreiber verwenden?

  Jeder Benutzername oder jedes Kennwort, dass Sie in den URL-String aufnehmen, wird bei der Verbindung mit der Server-Standardverbindung ignoriert. Die Methode DriverManager.getConnection() wann immer Sie sie aufrufen, eine neues Objekt Java Connection zurück. Beachten Sie, dass diese Methode zwar keine neue Datenbankverbindung erstellt (es wird nur eine implizite Verbindung verwendet), aber dafür ein neues java.sql.Connection-Objekt ausgibt.

  Noch einmal zur Erinnerung: Wenn der JDBC-Code im Zielserver ausgeführt wird, handelt es sich bei der Verbindung um einen impliziten Datenkanal und nicht um eine explizite Verbindungsinstanz wie sie etwa von einem Client ausgehen würde. Die Verbindung sollte niemals geschlossen werden.

• Ich erhalte einen OutofMemory Error, wenn ich einen höheren im Voraus abgerufenen Standardwert einstelle.

  Die Lösung besteht darin,die Anfangsgröße (-ms) und maximale Größe (-mx) des Pools für die Speicherzuteilung zu erhöhen. Ab der Version 11.1 sollte dies kein großes Problem mehr darstellen, da diese Versionen weniger Speicher als die 10g-Treiber benötigen. Eine eingehendere Erörterung dieses Problems finden Sie im Whitepaper „JDBC-Speichermanagement“ auf der JDBC OTN-Webseite.

• Was ist eine Service-Verbindungszeichenfolge?

  Oracle ersetzt den SID-Mechanismus zur Identifizierung von Datenbanken mit einem neuen Service-Ansatz. Dieser ist in der Datenbank seit Version 8.1.wi7 verfügbar. JDBC unterstützt Services in der Verbindungs-URL. Wir empfehlen dringend, so bald wie möglich von SIDs auf Services zu wechseln, da SIDs ab einer der nächsten Versionen der Datenbank nicht mehr unterstützt werden.

  Das grundlegende Format einer Service-URL ist:

  jdbc:oracle:thin:[<benutzer>/<kennwort>]@//<host>[:<port>]/<service> jdbc:oracle:oci:[<benutzer>/<kennwort>]@//<host>[:<port>]/<service>

  Beispiele:

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

  Weitere Informationen finden Sie im JDBC User Guide.

• Wie verbinde ich SYSDBA oder SYSOPER?

  Die einzige Möglichkeit dafür besteht in der Verwendung des Properties-Objekts bei der Verbindung. Es ist nicht möglich, den Benutzernamen und das Kennwort als Zeichenfolgen anzugeben. Fügen Sie den Benutzernamen in die Eigenschaft „Benutzer“ und das Kennwort in die Eigenschaft „Kennwort“ ein. Fügen Sie den Modus dann in die Eigenschaft „internal_logon“ ein. Dies funktioniert etwa folgendermaßen:

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

  Bei der Verbindung als SYSDBA oder SYSOPER mit dem Thin-Treiber muss das RDBMS für die Verwendung einer Kennwortdatei konfiguriert werden. Siehe dazu „Creating and Maintaining a Password File“ im „Oracle Database Administrator's Guide“.

• Welche Verschlüsselungsmethoden werden von den Oracle JDBC-Treibern unterstützt?

  Der JDBC-OCI-Treiber unterstützt dieselben Algorithmen wie der Datenbankserver.

  Bei den Versionen 11.1 und 11.2 unterstützt der JDBC-Thin-Treiber:

  • RC4_40
  • RC4_56
  • RC4_128
  • RC4_256
  • DES40C
  • DES56C
  • 3DES112
  • 3DES168
  • SSL
  • AES256
  • AES192
  • AES128
• Wie aktiviere ich beim JDBC-Thin-Treiber die Verschlüsselung und Prüfsummierung?

  Verwenden Sie, unter der Voraussetzung, dass der Server richtig konfiguriert ist, die folgenden Verbindungseigenschaften:

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

• Was versteht man unter Proxyauthentifizierung?

  Unter Proxyauthentifizierung versteht man die Fähigkeit, sich als Benutzer über einen anderen Benutzer anzumelden. Die Proxyauthentifizierung ermöglicht es zum Beispiel dem Middle Tier, sich einmal über einen „generischen“ Account zu authentifizieren und dann im Namen der tatsächlichen Benutzer eine Lightweight-Session einzurichten. Siehe dazu das JavaDoc zu oracle.jdbc.OracleConnection.openProxySession.

• Unterstützen Oracle JDBC-Treiber SSL?

  Ja, aber die Unterstützung ist treiberspezifisch. Die SSL-Verschlüsselung wird von den JDBC-OCI-Treibern seit Oracle JDBC 9.2.x und beim THIN-Treiber ab Version 10.2 unterstützt.

• Unterstützen die Oracle JDBC-Treiber LDAP in der Verbindungs-URL?

  Ja. Der JDBC-THIN-Treiber unterstützt in der Verbindungs-URL sowohl reguläres LDAP wie auch LDAP über SSL, zum Beispiel, wenn Oracle Internet Directory als LDAP-Provider verwendet wird. Weitere Informationen finden Sie im Oracle JDBC Developer's Guide und im Oracle Net Services Administrator's Guide.

• Wie kann ich JDBC mit einem Datenbankserver hinter einer Firewall verbinden?

  Im Allgemeinen wird empfohlen, Oracle Connection Manager für die Proxyverbindungen durch die Firewall zu verwenden. Öffnen Sie einen Port, der vom Oracle Connection Manager verwendet werden soll, und lassen Sie diesen den Rest erledigen. Sie sollten keinen Port direkt öffnen, der vom Datenbank-Listener verwendet wird, wie beispielsweise Port 1521.

  Im Oracle Net Services Administrator's Guide erfahren Sie, wie Sie den Oracle Connection Manager konfigurieren.

Anweisungen, PreparedStatements, CallableStatements

• Was ist defineColumnType und wann sollte ich es verwenden?

  defineColumnType ist eine Oracle JDBC-Erweiterung, die in manchen Fällen für eine bessere Performance sorgt. Bei früheren Versionen von Oracle JDBC profitierten alle Treiber von Aufrufen von  defineColumnType Aber seit Version 10.1.0 benötigt der Thin-Treiber diese bereitgestellten Informationen nicht mehr. Der Thin-Treiber erzielt eine maximale Performance, ohne defineColumnType aufrufen zu müssen. Die OCI- und serverseitigen internen Treiber erzielen immer noch eine bessere Performance, wenn die Anwendung defineColumnType verwendet.

  Falls Ihr Code sowohl mit Thin- wie auch mit OCI-Treibern verwendet wird, können Sie die Methode defineColumnType bei Verwendung des Thin-Treibers deaktivieren, indem Sie die Verbindungseigenschaf disableDefineColumnType auf „true“ setzen. Dadurch wird defineColumnType zu einem NOOP. Legen Sie diese Verbindungseigenschaft nicht fest oder stellen Sie sie auf „false“, wenn Sie OCI- oder serverseitige interne Treiber verwenden.

  defineColumnType kann auch dazu verwendet werden, um den Datentyp zu ändern. Oder auch, um die Größe von Daten mit variabler Länge zu begrenzen.

  Es gibt eine neue Variation davon mit einem 4. Parameter für form_of_use.

• Erzwingt ColumnType auf dem Server Konvertierungen?

  Nicht beim Thin-Treiber, aber bei den OCI- und serverseitigen internen Treibern.

• Wie kann man EscapeProcessing auf der Ebene des jdbc-Treibers deaktivieren, anstatt stmt.setEscapeProcessing(false) im Anwendungscode aufrufen zu müssen?

  Benutzen Sie die Eigenschaft ‚CONNECTION_PROPERTY_PROCESS_ESCAPES‘ in OracleConnection.

• Stellen Oracle JDBC-Treiber eine Bind-by-Name-Facility bereit?

  Ja. Weitere Informationen dazu finden Sie im JavaDoc zu oracle.jdbc.OraclePreparedStatement. Suchen Sie dort nach den Methoden setXXXAtName. Außerdem unterstützt oracle.jdbc.OracleCallableStatement das Binding von Argumenten zu PL/SQL-Prozeduren über die formalen Argumentnamen. Suchen Sie im JavaDoc nach den Methoden oracle.jdbc.OracleCallableStatement.setXXX(String, ...).

  Es ist dabei sehr wichtig, zu beachten, dass setXXX(String, XXX) das Binding über die formalen Parameternamen der aufgerufenen gespeicherten Prozedur vornimmt.. setXXXAtName(String, XXX) führt das Binding über den Namen des für Oracle typischen Parameters (:foo) in der ausgeführten SQL-Zeichenfolge durch. Beide sind sehr unterschiedlich und können zu sehr verschiedenen Ergebnissen führen.

• Wie bestimmen die Oracle JDBC-Treiber bei setXXX-Methoden in PreparedStatement den Datentyp?

  Allgemein ist jeder setXXX-Methode ein fester Datentyp zugeordnet, der dem Argumenttyp am sinnvollsten entspricht.

• Was geschieht, wenn der Typ des Zielparameters nicht mit dem identisch ist, der von der setXXX-Methode angenommen wird?

  Die Daten werden im Format des angenommenen Datentyps an den Server gesendet und der Server versucht diese zum Typ des Zielparameters zu konvertieren. Wenn eine Konvertierung nicht möglich ist , gibt der Server einen Fehler zurück und der Treiber löst in Ausführungszeit eine SQLException aus.

• Warum führen die Treiber die Konvertierung nicht auf der Clientseite durch?

  Bei SQL-Anweisungen könnten wir zuerst zum Server gehen, um die Informationen zum Typ zu erhalten, und dann die Konvertierungen durchführen. Aber das würde zusätzliche Roundtrips beinhalten. Der Code ist daher für den allgemeinen Fall optimiert, bei dem der JDBC-Programmierer die für den Spaltentyp am besten geeignete API verwendet.

• Was sind die Byte-Datentypen, um eine Spalte in eine Tabelle einzufügen?

  Für Byte-Daten gibt es drei Oracle SQL-Typen: RAW, LONG RAW und BLOB. RAW-Daten sind begrenzt, werden direkt in einer Spalte gespeichert und in Inline-Paketen an den Server übertragen. Die Begrenzung bei LONG RAW-Daten ist viel größer (2 Gigabyte), sie werden mittels eines speziellen Mechanismus neben der Zeile gespeichert und an den Server über einen Streaming-Callback-Mechanismus übertragen. BLOB-Daten sind in ihrer Länge praktisch unbegrenzt, werden von der Tabelle getrennt gespeichert und nur ein LOB-Positionsanzeiger wird in der Tabelle selbst abgelegt. Außerdem werden sie in getrennten Abläufen zum Server übertragen, bevor der Positionsanzeiger in der Tabellenspalte gespeichert wird.

• Was sind die Zeichendatentypen zum Einfügen in eine Tabellenspalte?

  Für Byte-Daten gibt es drei Oracle SQL-Typen: VARCHAR2, LONG und CLOB. VARCHAR2-Daten sind von begrenzter Länge, werden direkt in einer Spalte gespeichert und werden in Inline-Paketen an den Server übertragen. Die Begrenzung bei LONG-Daten ist viel größer (2 Gigabyte), sie werden mittels eines speziellen Mechanismus neben der Zeile gespeichert und an den Server über einen Streaming-Callback-Mechanismus übertragen. CLOB-Daten sind in ihrer Länge praktisch unbegrenzt, werden von der Tabelle getrennt gespeichert und nur ein LOB-Positionsanzeiger wird in der Tabelle selbst abgelegt. Außerdem werden sie in getrennten Abläufen zum Server übertragen, bevor der Positionsanzeiger in der Tabellenspalte gespeichert wird.

• Was sind die Größen für setString, setCharacterStream und setAsciiStream, und welche Größenbeschränkungen gelten für Binärdaten über setBytes und setBinaryStream?

  In der folgenden Tabelle finden Sie die Größenangaben für setString, setCharacterStream und setAsciiStream sowie die Größenbeschränkungen für Binärdaten über setBytes und setBinaryStream.

  Hinweis zu Binärdaten über setBytes und setBinaryStream:
  

  können ersetzt werden durch

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

  1. Der serverseitige interne Treiber kann keine Daten für BLOB-Parameter von SQL-Anweisungen konvertieren, die größer als 2.000 Byte sind. Bei PL/SQL-Anweisungen besteht diese Einschränkung nicht. Dies kann in vielen Fällen als Möglichkeit zur Umgehung des Problems genutzt werden, indem man ein Wrapping von SQL in PL/SQL vornimmt. Zum Beispiel bei einer Java-Zeichenfolge: insert into blob_tab (blob_col) values (?)
  2. Alternativ kann die Oracle-spezifische Methode setBytesForBlob als Workaround verwendet werden.

• Welche Größenbeschränkungen gelten für die proprietären Methoden setBytesForBlob und setStringForClob in oracle.jdbc.OraclePreparedStatement?

  Informationen zu den Größenbeschränkungen für die proprietären Methoden setBytesForBlob und setStringForClob in oracle.jdbc.OraclePreparedStatement finden Sie in der folgenden Tabelle.

  Hinweise: 
  

  1. Alternativ kann die Oracle-spezifische Methode setBytesForBlob als Workaround verwendet werden.
  2. Alternativ kann die Oracle-spezifische Methode setBytesForBlob als Workaround verwendet werden.
  
  

  
  

• Erzwingt ein Wechsel der Bind-Typen ein zusätzliches serverseitiges Parsen der Anweisung?

  Ja.

• Wie sieht es mit CallableStatements und Prozeduren mit IN OUT-Parametern aus?

  Die Datentypen des IN- und OUT-Parameters müssen identisch sein. Der automatische Wechsel führt zu Konflikten, es sei denn, der Benutzercode ändert ebenfalls den Typ in registerOutParameter. Ein besserer Ansatz ist es, IN OUT-Parameter in Fällen, wo dies zu einem Problem werden könnte, nicht zu verwenden. Dazu können Sie die ursprüngliche Prozedur ändern, indem Sie eine Wrapper-Prozedur oder einen PL/SQL-Block hinzufügen, der getrennte IN- und OUT-Parameter verwendet.

• Ändert sich die Auswahl der polymorphen PL/SQL-Prozeduren, wenn sich der Bind-Typ ändert?

  Ja. Beachten Sie, dass dies in Ihrem PL/SQL-Code ausgenutzt werden kann.

• Was ist mit vorhandenem Code?

  Vorhandener Code funktioniert weiterhin korrekt. Es gibt eine Änderung. Wenn zuvor eine Eingabe die Größenbeschränkung der verwendeten API überschritten hatte, wurde bei einem Aufruf der setXXX-API eine SCLQException ausgelöst. Jetzt tritt die Ausnahme, wenn überhaupt, in Ausführungszeit auf.

• In bestimmten Fällen erstellt der Treiber temporäre LOBs. Verfolgt er diese nach und gibt sie frei?

  Ja, sie werden nach der nächsten Ausführung der Anweisung oder beim Schließen der Anweisung freigegeben.

• Wir verwenden einen Zeichensatz mit variabler Breite wie UTF8. Führt der Treiber in Bezug auf die tatsächliche Länge einer Zeichenfolge Korrekturen durch?

  Ja. Abgesehen von der Entscheidung bei den größten Zeichenfolgen auf CLOB zu wechseln, die auf der Grundlage der angenommenen maximalen Größe erfolgt.

• Ist es bei einer wirklich großen Zeichenfolge eine gute Idee, z. B. setString zu verwenden?

  Wahrscheinlich ist es keine besonders gute Idee, einen derart großen String überhaupt erst zu erstellen. Ziehen Sie dazu die Anbieterdokumentation von Java Virtual Machine zu Rate, um zu erfahren, welche Effekte sehr große Objekte auf das Speicherverwaltungssystem von Java haben können.

• LONG RAW und LONG-Spaltentypen sind veraltet. Warum gibt es neue Verwendungsmöglichkeiten von setXXXStream-APIs?

  Die Stream-APIs sind nicht veraltet. Bei einigen Vorgängen bieten sie eine bessere Performance als die LOB-APIs und werden daher beibehalten.

• Die LOB-APIs sind aber viel flexibler, nicht wahr?

  Absolut! Die LOB-APIs ermöglichen einen wahlfreien Zugriff auf jeden Teil des LOB. Überlegen Sie, wo die jeweilige Verwendung angemessen wäre.

• Warum kann ich kein PreparedStatement erstellen, das select * from tab where id in (?, ?, ?, ...) ausführt?

  Das Problem ist, dass das RDBMS keine Bind-Parameter für die Elemente in der IN-Klausel unterstützt. Dies ist eine Einschränkung der Datenbank und nicht des Treibers.

• Was bedeutet „Exhausted Resultset: prepare_for_new_get“?

  Dieser Fehler tritt auf, wenn Sie versuchen, ein ResultSet zu verwenden, nachdem Sie es geschlossen haben. Dazu kommt es auch, wenn Sie die Anweisung, die das ResultSet erstellt hat, schließen.

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

• Warum muss ich ResultSets schließen?

  • Die unsprüngliche JDBC-Spezifikation erforderte, dass Verbindungen, Anweisungen und ResultSets geschlossen werden, wenn sie nicht länger erreichbar sind. Dazu müssen Finalizer verwendet werden. Finalizer beenträchtigen dramatisch die Performance aller Aspekte einer Anwendung, die in einer JVM mit Finalizern ausgeführt werden. Sun rät entschieden von ihrer Verwendung ab. Ein automatisches Schließen würde die Verwendung von Finalizern erfordern, was für alle Kunden nachteilig wäre, ob sie nun ein automatisches Schließen nutzen oder nicht. Das ist kein akzeptabler Kompromiss.

    Soweit wir das beurteilen können, implementiert kein JDBC-Treiber irgendeines Anbieters ein automatisches Schließen oder hat dies jemals getan – und zwar genau aus den oben aufgeführten Gründen. Diese Anforderung wurde aus den Spezifikationen entfernt, auch wenn einige Überbleibsel dieser Formulierung an manchen Stellen noch zu finden sein können. Das gilt auch für das JDBC-Tutorial. Das Tutorial ist zwar informativ und hilfreich, besitzt aber keine abschließende Gültigkeit. Es wurde schon seit Jahren nicht mehr aktualisiert. Die JDBC 4.0-Spezifikation erfordert definitiv kein automatisches Schließen.

    ResultSets, Anweisungen und Verbindungen nehmen alle sowohl auf der Clienten- wie auch auf der Serverseite Ressourcen in Anspruch. Solange diese Objekte geöffnet sind, werden die zugehörigen Ressourcen zugewiesen. Die Ressourcen werden nur freigegeben, wenn die Objekte geschlossen werden. Wenn ResultSets, Anweisungen, und/oder Verbindungen nicht geschlossen werden, gehen Ressourcen verloren, was sich auf die Performance Ihrer App auswirkt.

    Das Schließen einer Verbindung schließt alle dazugehörigen Anweisungen. Das Schließen einer Anweisung schließt alle dazugehörigen ResultSets. Wenn Sie also mit einer Verbindung fertig sind, können Sie diese einfach schließen und alle Anweisungen und ResultSets werden ebenfalls geschlossen. Dies ist eine akzeptable Programmierpraxis. Eine bessere Praxis ist es jedoch, Anweisungen und ResultSets explizit in finally-Blocks zu schließen. Dadurch wird Ihre Anwendung robuster und es werden nicht so schnell Ressourcen verschwendet, wenn sie weiterentwickelt wird, um sich ändernde Anforderungen zu erfüllen.

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

  
  

• Was geschieht mit DATE und TIMESTAMP?

  In diesem Abschnitt geht es um einfache Datentypen. :-)

  Vor der Version 9.2 ordneten die Oracle JDBC-Treiber den DATE-SQL-Typ java.sql.Timestamp zu. Dies war in soweit sinnvoll, als der Oracle DATE-SQL-Typ sowohl Datums- als auch Zeitinformationen enthält, genau wie java.sql.Timestamp. Die eigentlich näherliegende Zuordnung zu java.sql.Date war hingegen etwas problematisch, da java.sql.Date keine Zeitinformationen beinhaltet. Außerdem unterstützte das RDBMS den  TIMESTAMP-SQL-Typ nicht, sodass sich kein Problem daraus ergab, DATE to Timestamp zuzuordnen.

  In der Version 9.2 wurde die Unterstützung von TIMESTAMP zum RDBMS hinzugefügt. Der Unterschied zwischen DATE und TIMESTAMP besteht darin, dass TIMESTAMP Nanosekunden beinhaltet, DATE jedoch nicht. Deswegen wird DATE seit Version 9.2  Date und TIMESTAMP Timestamp zugeordnet. Leider gibt es ein Problem, wenn Sie DATE-Werte verwendet haben, um Zeitinformationen zu erfassen.

  Bei den Treibern der Versionen 9.2 bis 10.2 gibt es mehrere Möglichkeiten, dieses Problem zu beheben:

  • Ändern Sie Ihre Tabellen so, dass TIMESTAMP anstatt von DATE verwendet wird. Das ist wahrscheinlich nur selten möglich, aber falls es durchführbar ist, ist dies die beste Lösung.
  • Ändern Sie Ihre Anwendung so, dass über defineColumnType zur Definition der Spalten TIMESTAMP anstatt DATE verwendet wird. Diese Herangehensweise ist allerdings problematisch, da man es wirklich vermeiden sollte defineColumnType zu verwenden, es sei denn, es ist absolut erforderlich (siehe dazu Was ist defineColumnType und wann sollte ich es verwenden?).
  • Ändern Sie Ihre Anwendung, sodass getTimestamp anstatt getObject verwendet wird. Dies ist, sofern sie anwendbar ist, eine gute Lösung. Allerdings enthalten viele Anwendungen generischen Code, der getObject verwendet, also ist dies nicht immer möglich.
  • Aktivieren Sie die Verbindungseigenschaft V8Compatible. Dadurch werden die JDBC-Treiber angewiesen, die alte Zuordnung anstatt der neuen anzuwenden. Sie dies entweder als Verbindungs- oder als Systemeigenschaft festlegen. Sie können die Verbindungseigenschaft aktivieren, indem Sie sie zum Objekt java.util.Properties, das an DriverManager.getConnection weitergegeben wird, oder zu OracleDataSource.setConnectionProperties hinzufügen. Sie aktivieren die Systemeigenschaft durch Hinzufügen einer Option -D option in Ihrer java-Befehlszeile.java -Doracle.jdbc.V8Compatible="true" MyApp

  Ab Oracle JDBC 11.1 wird dieses Problem behoben. Ab dieser Version ordnet der Treiber SQL DATE-Spalten standardmäßig java.sql.Timestamp zu. Es ist nicht mehr notwendig, V8Compatible zu aktivieren, um die korrekte Zuordnung sicherzustellen. V8Compatible ist nun stark veraltet. Sie sollten es überhaupt nicht verwenden. Wenn Sie es auf „true“ setzen, hat dies zwar keine nachteiligen Auswirkungen, aber Sie sollten es überhaupt nicht mehr verwenden.

  Auch wenn es nur selten für diesen Zweck verwendet wurde, war V8Compatible nicht dafür vorgesehen, das Problem mit der Zuordnung von DATE zu beheben, sondern um die Kompatibilität mit 8i-Datenbanken zu unterstützen. 8i- (und ältere)-Datenbanken unterstützten den TIMESTAMP-Typ nicht. Durch das Aktivieren von V8Compatible wurde SQL DATE nicht nur Timestamp zugeordnet, wenn es aus der Datenbank ausgelesen wurde, es sorgte auch dafür, dass alle Timestamps beim Schreiben in die Datenbank zu SQL DATE konvertiert wurden. Seit 8i nicht mehr unterstützt wird, unterstützen auch die JDBC-Treiber der Version 11.1 diesen Kompatibilitätsmodus nicht mehr. Aus diesem Grund wird auch V8Compatible nicht mehr unterstützt.

  Wie oben bereits erwähnt, konvertieren die Treiber der Version 11.1 standardmäßig SQL DATE zu Timestamp, wenn dieses aus der Datenbank ausgelesen wird. Dies war immer die richtige Vorgehensweise und die Änderung bei Version 9i war ein Fehler. Bei den Treibern der Version 11.1 ist man zum richtigen Ansatz zurückgekehrt. Selbst, wenn Sie V8Compatible in Ihrer Anwendung nicht aktiviert haben, sollte sich diese in den meisten Fällen nicht anders verhalten. Sie sollten jedoch einen Unterschied feststellen, wenn Sie getObject verwenden, um eine DATE-Spalte zu lesen. Das Ergebnis ist ein Timestamp anstatt eines Date. Da Timestamp eine Unterklasse von Date ist, ist dies im Allgemeinen kein Problem. Sie stellen aber möglicherweise einen Unterschied fest, wenn Sie die Konvertierung von DATE zu Date genutzt haben, um die Zeitkomponente abzuschneiden oder toString auf den Wert anwenden. Andernfalls sollte die Änderung offensichtlich sein.

  Wenn Ihre App aus irgendeinem Grund sehr sensibel auf diese Änderung reagiert und sie zwingend das Verhalten der Versionen 9i–10g benötigen, gibt es eine Verbindungseigenschaft, die Sie aktivieren können. Setzen Sie mapDateToTimestamp auf „false“ und der Treiber kehrt zum standardmäßigen Verhalten der Versionen 9i–10g zurück und ordnet DATE zu Date zu.

• Was ist der längste Wert, den ich binden kann?

  Der nachstehenden Tabelle können Sie den längsten Wert entnehmen, den Sie binden können.

  In Version 9.2 kann setString() mit dem OCI-Treiber bis zu 64.000 Zeichen bei einem LONG einfügen und 4.000 Zeichen mit dem Thin-Treiber. In Version 10.1.0 haben wir den Grenzwert für beide Treiber auf 32.000 Zeichen festgelegt. Wir haben Verständnis dafür, dass die Reduzierung des Grenzwerts beim OCI-Treiber von 64.000 auf 32.000 für manche Kunden ein Problem darstellen kann. Aber angesichts der erheblichen Performance-Verbesserung, die durch diese Änderung ermöglicht wird, und der Tatsache, dass Oracle seinen Kunden dringend empfiehlt, von LONG auf CLOB zu wechseln, haben wir entschieden, dass diese Änderung der Architektur notwendig ist.

  Wir empfehlen Kunden, für die es erforderlich ist, dass setString() mehr als 32.000 Zeichen verarbeitet, einen Wechsel von LONG zu CLOB.

• Warum erhalte ich beim Lesen von einem TIMESTAMP WITH TIME ZONE ein anderes Ergebnis?

  Das alte Verhalten war nicht korrekt. Sie dazu Bug 4322830.

  Das alte Verhalten diente dazu, einen Timestamp zu erstellen, welcher einen Wert ausgeben würde, der identisch mit dem Datenbankwert ist. Aber da Timestamp sich auf die UTC-Zeitzone bezieht, würde dadurch ein Timestamp-Wert ausgegeben, der vom korrekten Wert abweicht. 8:00 Uhr am 1. Januar 2007 UTC ist nicht dasselbe wie 8:00 Uhr am 1. Januar 2007 PST. Hierbei handelt es sich um unterschiedliche Zeitpunkte.

  Wenn von der Datenbank 8:00 Uhr am 1. Januar 2007 PST eingelesen wird, erstellen die Treiber der Versionen 9i und 10g einen Timestamp mit dem Wert 8:00 Uhr am 1. Januar 2007 UTC. Diese Wert würde zwar„korrekt“ ausgegeben, also als „8:00 Uhr am 1. Januar 2007“, aber er würde sich offensichtlich auf den falschen Zeitpunkt beziehen. Die Treiber der Version 11.1 beheben diesen Bug.

• Wie sollte ich Instanzen von fortgeschrittenen Datentypen (Advanced Data Types, ADTs) erstellen?

  JDBC 4.0 führte auf der Schnittstelle Connection Factory-Methoden ein, um Instanzen von ADTs zu erstellen. Dies ist eine wesentliche bessere API als die Verwendung von Konstruktoren. Wir empfehlen Ihnen dringend, so weit wie möglich Factory-Methoden zu verwenden. Wir werden die Verwendung von Konstruktoren schon bald verwerfen und die Unterstützung für sie baldmöglichst beenden.

  Da die Standard-Factory-Methoden in JDBC 4.0 eingeführt wurden, sind diese Methoden nur bei den JSE 6-Treibern (ojdbc6.jar) verfügbar. Um proprietäre Oracle-Typen zu erstellen, sind die Factory-Methoden in OracleConnection sowohl für JSE 5 und JSE 6 (ojdbc5.jar and ojdbc6.jar) definiert. Wir empfehlen Ihnen noch einmal dringend, Factory-Methoden zu verwenden.

• Warum wird die Standard-Factory-Method createArrayOf nicht unterstützt?

  Der Standard-SQL-Array-Typ ist anonym, was bedeutet, dass der Typ „array of foo“ keinen Namen hat. Nur der Elementtyp ist benannt. In Oracle SQL ist der Array-Typ jedoch benannt. Tatsächlich werden anonyme Array-Typen nicht unterstützt. Daher fasst die Standard-Factory-Methode in JDBC 4.0 den Elementtyp als Argument auf und erstellt eine Instanz eines anonymen Array-Typs. Die Oracle JDBC-Treiber definieren eine proprietäre Oracle-Methode, createArray, die den Namen eines Array-Typs einliest und eine Instanz dieses benannten Array-Typs ausgibt. Dies ist übrigens aufgrund der Definition von Oracle SQL erforderlich. Derzeit kann die Datenbank von Oracle die Standard-Methode createArrayOf in JDBC 4.0 nicht unterstützen.

• Was macht DBMS_LOB.ERASE?

  Es „bereinigt“ nur ein Segment des CLOB. Das CLOB wird aber *nicht* verkürzt. Die Länge des CLOB ist also vor und nach dem LÖSCHEN identisch. Um ein CLOB zu verkürzen, können Sie DBMS_LOB.TRIM verwenden.

• Kann ich oracle.sql.CLOB.putChars() verwenden?

  Ja, das können Sie. Aber Sie müssen dabei sicherstellen, dass die Positions- und Längenargumente korrekt sind. Sie können auch die empfohlene OutputStream-Schnittstelle verwenden, die wiederum putChars für Sie aufruft.

• OCI stellt Funktionen zur Bearbeitung eines CLOB CharSetld zur Verfügung. Was ist das Äquivalent davon bei JDBC?

  In JDBC sind CLOBs *immer* in USC2, dem Zeichensatz von Oracle, der dem Java-Typ „char “ entspricht. Es gibt also keine Entsprechung für das CLOB CharSetId von OCI.

• Ist das Schreiben in BLOBS langsamer als das Einfügen von LONG RAWs?

  Das kommt darauf an. Beim Schreiben kleiner Werte von weniger als 10.000 sind LONG RAWs schneller. Beim Schreiben größerer Werte verschwindet der Unterschied.

• Warum erhalte ich einen ORA-03127-Fehler , wenn ich LobLength im Stream-Beispielcode erhalte?

  Dieses Verhalten ist korrekt. LONG-Spalten werden nicht in-place (d. h. in der Zeile) ‚geholt‘. Sie werden an anderer Stelle geholt und bestehen in der Pipe, bis Sie explizit von Ihnen gelesen werden. In diesem Fall haben wir den LobLocator (getBlob()) und versuchen die Länge dieses LOB zu erhalten, bevor wir die LONG-Spalte lesen. Da diese Pipe nicht frei ist, erhalten wir die oben genannte Ausnahme. Die Lösung besteht darin, das Lesen der Long-Spalte abzuschließen, bevor Sie irgendeinen Vorgang am BLOB ausführen.

• Wenn ich ein CLOB aus der Datenbank abrufe und aktualisiere, werden meine Änderungen manchmal nicht in der Datenbank angezeigt. Woran liegt das?

  Oracle LOBs verwenden eine Wertesemantik. Wenn Sie ein LOB aktualisieren, müssen Sie das LOB wieder in die Datenbank schreiben, damit die Änderungen angezeigt werden. Aus technischen Gründen werden Ihre Änderungen manchmal gespeichert, obwohl Sie das LOB nicht schreiben. Aber Sie haben keine Möglichkeit, vorauszusehen, wann dies der Fall ist. Daher sollten Sie das LOB immer schreiben.

• Wie kann ich ein oracle.sql.REF zwischen zwei verschiedenen JDBC-Clients (EJBs, JDBC-Clients usw.) übergeben? Denn die REF-Klasse ist schließlich nicht serialisierbar, oder?

  Das traf früher zu, ist aber nicht mehr der Fall. REF ist jetzt serialisierbar.

  Der folgende Hinweis kann aber weiterhin nützlich sein, falls Sie eine ältere Version des Oracle JDBC-Treibes verwenden, bei dem REFs noch nicht serialisierbar sind.

  Die wichtigen Bestandteile der REF-Klasse sind das Byte-Array, das die Objektreferenz und den vollständig qualifizierten Namen des Objekts repräsentiert. Sie können eine Klasse wie die folgende Klasse „SomeREF“ verwenden, um die Bytes und den Typennamen aus einem Objekt-REF aufzunehmen. Diese Klasse ist serialisierbar. Sie kann die REF mit ihrer Methode„toREF“, die eine JDBC-Verbindung erfordert, neu erstellen.

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

• Wie kann ich eine neue REF erstellen?

  • Sie können Abfragen zu einer Tabelle ausführen, die REF zu Oracle8-Objekttypen beinhaltet, und die REF wird von JDBC als Java oracle.sql.REF materialisiert. JDBC unterstützt nicht die komplette Neuerstellung von REFs. Sie müssen stattdessen zur Datenbank wechseln und die neue REF in SQL einfügen. Dann müssen Sie die REF wieder auswählen und an den Client zurücksenden.

    Dies lässt sich einfacher mit einem PL/SQL-Block ausführen. Wenn Sie zum Beispiel die folgenden Tabellen verwenden:

    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); Sie können einen neuen Punktwert in point_values_table einfügen, eine neue ref in point_ref_table und die REF mit dem folgenden Code an den Client zurücksenden: 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);

  
  

• Was sind OPAQUE-Typen?

  OPAQUE-Typen weisen binäre Daten auf und verfügen über unterstützende Methoden, die in einer Server-nativen Code-Library definiert sind. Sie sind nur für die interne Verwendung durch Oracle verfügbar.

• Wenn ich nach dem Ausführen das Attribut für die Scrollbarkeit festlege, hat dies keinen Effekt auf die Scrollbarkeit von RowSet. Woran liegt das?

  Die Eigenschaften eines Beans können wie folgt klassifiziert werden:

  • Objekterstellungseigenschaften
  • Laufzeiteigenschaften

  Objekterstellungseigenschaften sollten vor der Erstellung des Objekts festgelegt werden , da es sich bei ihnen um die Schlüsseleigenschaften für die Objekterstellung handelt. Die Laufzeiteigenschaften können jederzeit festgelegt werden und sie verändern das Verhalten des Beans in Laufzeit.

  Scrollbarkeit, Benutzername und Kennwort sind alles Objekterstellungseigenschaften. Beim Autocommit-Status, der Anzahl der Vorabrufe usw. handelt es sich jeweils um Laufzeiteigenschaften. Üblicherweise wird das Hintergrundobjekt während execute/setCommand aktiviert, sodass alle Anweisungserstellungsattribute davor festgelegt werden sollten. Da für die Erstellung von Anweisungs-URLs, Benutzernamen, Kennwörtern usw. ein Verbindungsobjekt erforderlich ist, sollte dies vor dem Festlegen des Befehls festgelegt werden.

• Kann ich das Objekt RowSet in eine Flat File serialisieren, obwohl das RowSet Streams enthält?

  Ja, die serialisierbaren Streams ermöglichen Ihnen das Stream-Objekt auf jedem serialisierbaren Medium wie einer Flat File, Netzwerkverbindung usw. zu serialisieren. Diese Funktion steht nur bei CachedRowSet zur Verfügung. Es ist möglich, CachedRowSet auf einer Maschine zu erstellen, wo die JDBC-Treiber vorhanden sind, und es dann zu einem Remote-Client zu verschieben, wo nur Rowset-Binärdateien vorhanden sind, aber nicht die Treiber-Binärdateien. Der Remote-Client kann RowSet durch Einfügen, Löschen oder Aktualisieren ändern. Senden Sie sie dann zu dem Ort zurück, bei dem die JDBC-Treiber und RowSet-Binärdateien vorhanden sind, um die modifizierten Werte in der Datenbank zu synchronisieren.

• Kann der JDBC-Thin-Treiber zur Entwicklung von Java-Anwendungen verwendet werden?

  Ja, der JDBC-Thin-Treiber kann zur Entwicklung von Java-Anwendungen verwendet werden. Im Gegensatz zum JDBC-OCI-Treiber funktioniert der JDBC-Thin-Treiber allerdings nur mit TCP/IP-basierten Netzwerken. Benutzer, die Anwendungen auf Nicht-TCP/IP-Netzwerken ausführen, sollten den JDBC-OCI-Treiber verwenden.

• Wann sollte ich den internen Servertreiber verwenden?

  Sie sollten den internen Servertreiber verwenden, wenn Sie auf die Datenbank in einer gespeicherten Java-Prozedur zugreifen. Eine gespeicherte Java-Prozedur ist eine Java-Methode, die im Oracle RDBMS ausgeführt wird, genau so, wie PL/SQL im RDBMS ausgeführt wird. Da sie im RDBMS ausgeführt wird, erfolgt die Ausführung notwendigerweise während einer Datenbank-Session. Der interne Servertreiber bietet den Zugriff auf diese Datenbank-Session. Wenn Ihr Code also in einer gespeicherten Java-Prozedur ausgeführt wird und sie auf die Datenbank zugreifen möchten, müssen Sie den internen Servertreiber verwenden. Eine Ausnahme stellen die seltenen Fälle dar, in denen Sie den Thin-Servertreiber verwenden sollten.

• Wann sollte ich den Thin-Servertreiber verwenden?

  In einer gespeicherten Java-Prozedur sollten Sie üblicherweise den internen Servertreiber verwenden. Er stellt eine Verbindung zur selben Session her, in welcher die gespeicherte Prozedur ausgeführt wird. Aber vielleicht möchten Sie sich manchmal auch mit einer anderen Datenbank oder einer neuen Session in derselben Datenbank verbinden. In beiden Fällen müssen Sie den Thin-Servertreiber verwenden.

• DriverManager.getConnection gibt den Fehler „Kein geeigneter Treiber“ aus

  Stellen Sie sicher, dass der Treiber registriert ist und dass Sie eine Verbindungs-URL verwenden, die konsistent mit Ihrem JDBC-Treiber ist. Siehe dazu auch „Die JDBC-Treiber von Oracle mit den richtigen Werten verwenden“.

• Fehlermeldung: „UnsatisfiedLinkError bei OCI-Treiber“

  Wenn Sie Win NT oder Win95 verwenden, zeigt die Java Virtual Machine an ,dass sie OCI73JDBC.DLL nicht laden kann, falls eine der DLLs, die von OCI73JDBC.DLL aufgerufen werden, nicht geladen werden kann. Die JDBC-OCI-Treiber verwenden Shared Librarys, welche die C-Codeteile des Treibers enthalten. Beim Oracle7-Client-Programm ist diese Library OCI73JDBC.DLL. Die Shared Library wird normalerweise in [ORACLE_HOME]\BIN installiert, wenn Sie den JDBC-Treiber aus der Verteilung installieren. Stellen Sie sicher, dass sich das Verzeichnis in Ihrem PFAD befindet. Weitere Einzelheiten finden Sie im Abschnitt zur Installation der Dokumentation.

  Die Shared Library hängt auch von anderen Librarys ab. Falls eine dieser DLLs fehlen sollte, führt dies zu einer Fehlermeldung, dass OCI73JDBC.DLL fehlt. JDBC OCI7 erfordert die folgenden Oracle7-Dateien: CORE35.DLL, CORE35O.DLL, NLSRTL32.DLL und ORA73.DLL

  Die Java Virtual Machine (JavaSoft JDK) ist JAVAI.DLL.

  The Microsoft Visual C++-Laufzeit ist MSVCRT.DLL, MSVCRTI.DLL, MSVCRT20.DLL und MSVCRT40.DLL.

  Sie finden die Liste der abhängigen DLLs, indem Sie zum Windows Explorer-Programm wechseln, einen Rechtsklick auf die DLL ausführen und Schnellansicht auswählen. Der Bildschirm der Schnellansicht zeigt unter anderem die Importtabelle, welche die abhängigen DLLs aufführt. Sie können die fehlenden erforderlichen Supportdateien von der Oracle-Installations-CD neu installieren. Installieren Sie „Required Support Files 7.3.4“, „SQL*Net Client 2.3.4“ und „Oracle TCP/IP Protocol Adapter 2.3.4c“.

• Fehlermeldung: „ORA-1019: Speicher kann nicht zugewiesen werden.“

  Sie verwenden den OCI8-Treiber bei einer Oracle7-Client-Installation. Verwenden Sie stattdessen den OCI17-Treiber.

• Fehlermeldung: „ORA-01000: maximale Anzahl offener Cursor überschritten“

  Die Anzahl der Cursor, die ein Client auf einer Verbindung auf einmal öffnen kann, ist begrenzt (50 ist der Standardwert). Sie müssen die Anweisung explizit mit der Methode method stmt.close() schließen, um die Cursor zu schließen und freizugeben.

  Wenn Sie die Cursor nicht explizit schließen, werden Sie irgendwann diese Fehlermeldung erhalten. Sie können dieses Problem vorübergehend umgehen, indem Sie den Grenzwert für „OPEN\_CURSORS“ erhöhen. Dies kaschiert jedoch lediglich das Problem, anstatt es zu beheben. Es liegt in Ihrer Verantwortung, Cursor, die Sie nicht länger benötigen, zu schließen.

• Fehlermeldung: „ORA-01002: „FETCH auf ungültigen oder geschlossenen Cursor“

  Bei einer JDBC-Verbindung ist AutoCommit standardmäßig aktiviert. Aber um eine SQL zu verwenden, die ‚to update‘ beinhaltet, müsse Sie AutoCommit deaktivieren.

  Die Lösung ist also, AutoCommit auf ‚false‘ einzustellen.

• Fehlermeldung: „ORA-12705: ungültiger oder unbekannter NLS-Parameterwert spezifiziert“

  Versuchen Sie, NLS_LANG explizit festzulegen. Wenn NLS_LANG nicht oder nicht korrekt festgelegt ist, haben Sie womöglich einen anderen Client als Oracle7.3.4. Installieren Sie auf dem Client Oracle7.3.4.

• Fehler beim Abrufen von Text für Fehler ORA-12705.

  Auf dem Client ist keine Oracle-Installation vorhanden oder die Installation wurde nicht ordnungsgemäß abgeschlossen. Falls Sie dies noch nicht getan haben sollten, führen Sie mit der Oracle Server-Installations-CD eine „Oracle Client-Installation“ durch, um die erforderliche Software auf Ihrem Client-Rechner aufzusetzen. Falls Sie dies bereits getan haben, überprüfen Sie, ob die Installation tatsächlich richtig abgeschlossen wurde. Wenn dies nicht der Fall sein sollte, entfernen Sie die Installation und installieren Sie sie neu.

  Beachten Sie, dass es zu diesem Fehler kommen kann, wenn Sie eine Client-Installation durchführen und dann vergessen, ORACLE_HOME festzulegen. Wenn Sie über die Umgebungsvariable von ORACLE_HOME nicht verfügen sollten, sollte ein einfaches Festlegen/Exportieren der Umgebungsvariable das Problem beheben, ohne dass die Client-Seite neu installiert werden müsste.

• Fehlermeldung: Der JDBC-Thin-Treiber zeigt mir für Unicode Literale den Fehler „ungültiges Zeichen“ an.

  Beim JDBC-Thin-Treiber sind bei Literalen, die Unicode-Zeichen enthalten, doppelte Anführungszeichen erforderlich. Zum Beispiel:

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

• Vorgänge zum EINFÜGEN oder UPDATES sind langsam

  Standardmäßig führt der Treiber das Commit für alle EINFÜGE- und UPDATE-Vorgänge aus, sobald Sie die Anweisung ausführen. Dies wird in JDBC als AutoCommit-Modus bezeichnet. Sie erhalten möglicherweise eine bessere Performance, wenn Sie AutoCommit deaktivieren und explizite Commit-Anweisungen verwenden. Verwenden Sie den setAutoCommit-Einstiegspunkt der Klasse Connection, um AutoCommit zu deaktivieren.

  connection.setAutoCommit(false); Weitere Information zu den Oracle-Erweiterungen für Aufrufe für die Batchverarbeitung zum EINFÜGEN und von UPDATES finden Sie in der JDBC-Dokumentation zur Batchverarbeitung von Updates. Die Batchverarbeitung dieser Befehle kann sogar noch höhere Geschwindigkeiten ermöglichen als das Deaktivieren von AutoCommit.

• Fehlermeldung: „Verbindung von Peer zurückgesetzt“

  Üblicherweise ist dies ein Fehler, der angezeigt wird, wenn der Server abstürzt, während Sie mit ihm verbunden sind. Möglicherweise wird gerade eine Verbindung hergestellt oder Sie nutzen bereits eine hergestellte Verbindung. In beiden Fällen sollten Sie die serverseitigen Logdateien prüfen, um festzustellen, welche Fehler und Stack-Dumps auf dem Server ausgelöst wurden.

  Beachten Sie, dass dieser Fehler sich von dem unterscheidet, der auftritt, wenn Sie versuchen, eine Verbindung zu einem falschen/ungültigen Port oder gar Rechner herzustellen. Im letzteren Fall erhalten Sie eine andere Fehlermeldung als diese. Der Fehler, der angezeigt wird, wenn der Server ausgefallen ist und keine Verbindungsanforderungen akzeptiert, ist ebenfalls ein anderer.

• Was bedeutet „Protokollverletzung“?

  Der Thin-Treiber löst diese Ausnahme aus, wenn er etwas aus dem RDBMS liest, das er nicht erwartet hat. Das bedeutet, dass die Protokoll-Engine im Thin-Treiber und die Protokoll-Engine im RDBMS nicht synchronisiert sind. Es gibt keine Möglichkeit, diesen Fehler zu beheben. Die Verbindung ist fehlgeschlagen. Sie sollten versuchen, sie zu schließen. Aber das wird wahrscheinlich ebenfalls scheitern.

  Falls Sie einen reproduzierbaren Testfall erhalten, der diesen Fehler generiert, senden Sie bitte eine TAR-Datei an Oracle Global Support. Geben Sie bitte die genauen Versionsnummern des JDBC-Treibers und des RDBMS an, einschließlich aller Patches

• Gibt es irgendwelche Demo-Programme zu JDBC?

  Ja. Sehen Sie in  $ORACLE_HOME/jdbc/demo/demo.tar auf UNIX-Systemen und in $ORACLE_HOME/jdbc/demo/demo.zip auf Windows-Systemen nach.

• Wie führe ich die Demos aus?

  Dekomprimieren Sie demo.tar oder demo.zip file. Sie werden dann die Datei „Samples-Readme.txt“ sehen. Lesen Sie diese Datei zuerst, um einen Überblick über die JDBC-Demos zu erhalten. Führen Sie dann Makefile auf UNIX aus oder rufen Sie rundemo.bat auf Windows auf.

• Was sollte ich tun, wenn bei der Ausführung einer Demo ein Fehler auftritt.

  Die JDBC-Demos sollten fehlerfrei ausgeführt werden. Wenn ein Fehler auftritt, geht dieser möglicherweise auf ein Problem in Ihrer Konfiguration zurück. Prüfen Sie Folgendes:

  • Classpath
  • die korrekten JDK-Versionen
  • Informationen zu den Anforderungen vor der Durchführung von Tests finden Sie in Samples-Readme.txt, Makefile, und jeder .java-Datei.

• Was ist die JDBC Trace Facility?

  Die JDBC Trace Facility ist eine Laufzeit-Debugging-Hilfe, die in frühere Versionen von Oracle JDBC integriert ist. Wenn sie aktiviert ist, gibt sie Meldungen zur Ausführung des Oracle JDBC-Treibers aus. Diese Meldungen beinhalten üblicherweise den Methodeneinstieg, Parameterwerte, den signifikanten internen Zustand, interne Fehler, das Methodenende und die Rückgabewerte.

  Ab Version 10.1.0 wird die Oracle Trace Facility nur in classes12_g.jar und classes12dms_g.jar unterstützt. Alle Oracle JDBC-Treiber, die JDK 1.4 und höhere Versionen unterstützen, verwenden die integrierte Trace Facility in java.util.logging. Im Abschnitt zu java.util.logging finden Sie weitere Informationen, wie Sie Trace-Informationen erhalten, wenn Sie JDBC 11, ojdbc14_g.jar oder ojdbc14dms_g.jar verwenden.

  Falls Sie mit Ihrer JDBC-Anwendung Schwierigkeiten haben sollten, finden Sie das Trace möglicherweise hilfreich. Die meisten Meldungen beziehen sich auf interne JDBC-Methoden und sind daher möglicherweise unklar. Aber sie mögen immer noch etwas Hilfe bieten. Ich würde vorschlagen,  zunächst das Trace-Volume auf 1 zu setzen.

  Falls Sie der Ansicht sind, dass in JDBC ein Bug aufgetreten ist, kann uns das Trace möglicherweise dabei helfen, Sie zu unterstützen. In diesem Fall sollten Sie das standardmäßige Trace-Volumen übernehmen. Aufgrund der großen Ausgaben, die dadurch erfolgen, sollten Sie entweder einen kleinen Testfall nachverfolgen oder nur einen begrenzten Teil einer größeren Anwendung. Stellen Sie sicher, dass Sie den etnsprechenden Code fvor dem Fehler mit angeben.

• Wie aktiviere ich das alte JDBC-Trace?

  Informationen, wie Sie Trace-Informationen bei der Verwendung von JDBC 11 abrufen können, finden Sie im Abschnitt zu java.util.logging.

  Um die JDBC Trace Facility zu verwenden, müssen Sie eine Debug-JAR-Datei verwenden: classes12_g.jar oder classes12dms_g.jar. Falls Sie versuchen, das Trace zu verwenden, während Sie eine der anderen JAR- oder ZIP-Dateien benutzen, erhalten Sie entweder eine Fehlermeldung oder gar keine Ausgabe.

  Es gibt zwei Möglichkeiten, das Trace zu steuern: programmgesteuert oder über Eigenschaften. Die programmgesteuerte API ermöglicht es ihnen, das Trace zu aktivieren und zu deaktivieren sowie andere Eigenschaften zu ändern, während Ihre Anwendung ausgeführt wird. Angesichts des oft hohen Volumens von Trace-Daten ist es häufig ratsam, das Trace nur bei besonders verdächtigen Teilen des Codes zu aktivieren. Falls die Anwendungsquelle nicht einfach geändert werden kann, können Sie das Trace über Eigenschaften steuern. Diese Eigenschaften werden einmal beim Start der Anwendung gelesen, danach jedoch nicht mehr. Sie können auch Eigenschaften und die API gleichzeitig verwenden. Die Eigenschaften legen dann den Anfangszustand fest, während die API diesen ändert.

  Die einfachste Methode zum programmgesteuerten Aktiveren des Trace ist ein Aufruf von

  oracle.jdbc.driver.OracleLog.startLogging(); Dadurch wird das Trace an System.out gesendet. Nutzen Sie zum Deaktivieren den Aufruf:

  oracle.jdbc.driver.OracleLog.stopLogging(); Sie können das Trace auch aktivieren, indem Sie die Systemeigenschaft  oracle.jdbc.Trace auf „true“ setzen. java -Doracle.jdbc.Trace=true MyApp Das Festlegen irgendwelcher anderen Eigenschaften von JDBC Trace Facility, die unten beschrieben werden, setzt oracle.jdbc.Trace implizit auf „true“.

• Wie kann ich das Volumen der Trace-Ausgabe steuern?

  Informationen, wie Sie Trace-Informationen bei der Verwendung von JDBC 11 abrufen können, finden Sie im Abschnitt zu java.util.logging.

  Die JDBC Trace Facility kann ein großes Ausgabevolumen erzeugen. Die einfachste Möglichkeit das Volumen zu steuern ist, das Trace nur zu aktivieren, wenn es benötigt wird.

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

  oracle.jdbc.driver.OracleLog.stopLogging(); Dies ist aber oft nicht möglich. Sie können auch durch Festlegen des Trace-Volumens die Anzahl der Trace-Mitteilungen reduzieren. oracle.jdbc.driver.OracleLog.setLogVolume(1); Der Standardwert beträgt 2. Der Höchstwert ist 3, aber derzeit ergibt dies nicht viel mehr als 2. 1 ist weitaus kleiner als der Standardwert.

  Sie können die Größe jeder Zeile steuern, indem Sie eine explizite Zeilengröße festlegen oder ändern, welche Felder auf der jeweiligen Zeile ausgegeben werden. So ändern Sie die maximale Zeilenlänge:

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

  Um zu steuern, welche Felder ausgegeben werden, können Sie die Eigenschaft oracle.jdbc.PrintFields festlegen.

  java -Doracle.jdbc.PrintFields=none MyApp Zulässige Werte sind:

  • none – es wird einfach die Mitteilung ausgegeben
  • default
  • thread – identisch mit default aber auch der Threadname wird ausgegeben
  • all
• Wohin geht die Trace-Ausgabe?

  Informationen, wie Sie Trace-Informationen bei der Verwendung von JDBC 11 abrufen können, finden Sie im Abschnitt zu java.util.logging.

  Standardmäßig geht die Trace-Ausgabe zu System.out. Sie können Sie jedoch jederzeit mit der Eigenschaft oracle.jdbc.LogFile woandershin senden.

  java -Doracle.jdbc.LogFile=/tmp/jdbc.log MyApp oder durch Aufrufen der setLogStream-API. oracle.jdbc.driver.OracleLog.setLogStream(System.err); Das Festlegen des Logstreams startet das Trace ebenfalls. Sie können das Trace deaktivieren, indem Sie den Logstream auf Null setzen.

• Wie kann ich DMS in einer DMS-fähigen JAR-Datei deaktivieren?

  Es gibt eine Systemeigenschaft oracle.dms.console.DMSConsole. Wenn diese Eigenschaft nicht festgelegt ist, ist DMS aktiv. Wenn Sie auf oracle.dms.instrument_stub.DMSConsole gesetzt ist, wird eine Stub-Implementierung verwendet, die DMS effektiv deaktiviert. Eine Möglichkeit, wie eine Anwendung es deaktivieren kann, ist der Aufruf

  System.setProperty( "oracle.dms.console.DMSConsole", "oracle.dms.instrument_stub.DMSConsole"); Dieser muss erfolgen, bevor DMS-Code ausgeführt wird. Eine weitere Möglichkeit wäre die Verwendung der Option -D der Java VM. java -Doracle.dms.console.DMSConsole=oracle.dms.instrument_stub.DMSConsole MyApp

• Kann ich JDBC-Programme mit Symantec Visual Cafe debuggen?

  Visual Cafe wird nicht mehr unterstützt.

• Kann ich JDBC-Programme mit Visual J++ von Microsoft debuggen?

  Visual J++ wird nicht mehr unterstützt.

• Können die JDBC-Treiber auf gespeicherte PL/SQL-Prozeduren zugreifen?

  Ja, sowohl der Oracle JDBC-OCI-Treiber als auch der JDBC-Thin-Treiber unterstützen die Ausführung gespeicherter PL/SQL-Prozeduren und anonymer Blöcke. Sie unterstützen sowohl die SQL:2003-Escape-Syntax als auch die Oracle-Escape-Syntax. Die folgenden PL/SQL-Aufrufe sind über beide Oracle JDBC-Treiber verfügbar:

  • 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;");
• Unterstützen die JDBC-Treiber Streaming?

  Ja, sowohl der Oracle JDBC-OCI-Treiber wie auch der JDBC-Thin-Treiber unterstützen das Streaming von Daten zwischen Client und Server in beide Richtungen. Sie unterstützen sämtliche Stream-Konvertierungen – binär, ASCII, und Unicode. Weitere Informationen finden Sie im Stream-Tutorial in der Dokumentation zu Oracle JDBC-Treibern.

• Unterstützen die JDBC-Treiber Mehrbyte-Zeichensätze?

  Ja, sowohl der Oracle JDBC-OCI-Treiber wie auch der JDBC-Thin-Treiber unterstützen Mehrbyte-Zeichensätze – sie können beide auf Datenbanken zugreifen, die einen beliebigen Oracle-Zeichensatz verwenden. Sie konvertieren Mehrbyte-Zeichen zu Unicode 1.2. Der JDBC-OCI-Treiber wurde getestet und unterstützt alle europäischen Zeichensätze sowie sämtliche asiatischen Zeichensätze, einschließlich Chinesisch, Japanisch und Koreanisch.

• Funktionieren die JDBC-Treiber mit Firewalls?

  Ja, sowohl der JDBC-OCI-Treiber wie auch der JDBC-Treiber funktionieren in einem Intranet- und einem Extranet-Umfeld. Bei einer Extranet-Bereitstellung können die Treiber mit den meisten branchenführenden Firewalls verwendet werden, die SQL*Net-zertifiziert sind. Derzeit haben die folgenden Anbieter ihre Firewalls bei SQL*Net zertifiziert:

  • Stateful Inspection Firewalls: Firewalls von Checkpoint, SunSoft und CISCO Systems.
  • Proxybasierte Firewalls: Firewalls von Milkyway Networks, Trusted Information Systems, Raptor, Secure Computing Corporation und Global Internet.
• Unterstützen die JDBC-Treiber von Oracle PL/SQL-Tabellen/-Ergebnismengen/-Datensätze/-Booleans?

  Nein. Oracle JDBC-Treibern ist es nicht möglich, das Aufrufen oder Ausgeben von Werten der PL/SQL-Typen TABLE (jetzt als Indexed-by Tables bezeichnet), RESULT SET, RECORD oder BOOLEAN zu unterstützen. Es gibt derzeit keine Pläne, dies zu ändern. Stattdessen wird empfohlen, RefCursor, Oracle Collections und strukturierte Datentypen zu verwenden.

  Als Workaround können Sie Wrapper-Prozeduren erstellen, welche die Daten als Typen verarbeiten, die von JDBC unterstützt werden.

  Um zum Beispiel eine gespeicherte Prozedur zu wrappen, die PL/SQL-Booleans verwendet, können Sie eine gespeicherte Prozedur erstellen, die ein Zeichen oder eine Zahl aus JDBC übernimmt und es an die ursprüngliche Prozedur als BOOLEAN weitergibt oder, bei einem Ausgabeparameter ein BOOLEAN-Argument von der Ursprungsprozedur entgegennimmt und es als CHAR oder NUMBER an JDBC übergibt. In ähnlicher Weise können Sie zum Wrappen einer gespeicherten Prozedur, die PL/SQL-Datensätze verwendet, eine gespeicherte Prozedur erstellen, die einen Datensatz in seinen einzelnen Komponenten verarbeitet (wie CHAR und NUMBER). Um eine gespeicherte Prozedur zu wrappen, die PL/SQL-Tabellen verwendet, können Sie Daten in ihre Komponenten zerlegen oder vielleicht auch Oracle-Collection-Typen verwenden.

  Hier ist das Beispiel einer PL/SQ-Wrapper-Prozedur MY_PROC für eine gespeicherte Prozedur PROC, die als Eingabewert ein BOOLEAN entgegennimmt:

  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;

• Wird Failover unterstützt?

  Ja. Wenn Sie eine Verbindung zu einem RAC-Server herstellen, sorgt Fast Connection Failover für eine schnelle Reaktion auf Fehlerereignisse. Diese neue Hochverfügbarkeitsfunktion ist treiberunabhängig und arbeitet mit Implicit Connection Cache und RAC zusammen, um eine maximale Verfügbarkeit der Verbindungen im Cache sicherzustellen. Dies wird dadurch erreicht, dass die Down-Ereignisse von RAC verarbeitet werden, um ungültige Verbindungen zu entfernen und Up-Ereignisse, um ein Load Balancing bestehender Verbindungen durchzuführen.

  Wenn Sie den OCI-Treiber verwenden und nur einen Failover für Abfragen benötigen, sollten Sie TAF in Betracht ziehen. TAF ermöglicht in erster Linie das Abfrage-Failover in einer Anwendung. Es handelt sich dabei nicht um einen allgemeinen Failover-Mechanismus. Beachten Sie, dass Fast Connection Failover und TAF nicht zusammen verwendet werden können. Nur eines davon kann jeweils aktiviert und verwendet werden.

• Wie unterstützen die JDBC-Treiber Oracle ROWID-Datentypen? Was hat dies mit getCursorName und setCursorName zu tun?

  Wir unterstützen die getCursorName- und setCursorName-JDBC-Einstiegspunkte nicht. Stattdessen stellen wir Zugriff zu ROWIDs bereit, die eine ähnliche Funktionalität bieten. DBC 4.0 definiert java.sql.Rowid  das vollständig kompatibel mit oracle.sql.ROWID ist und von den JSE 6 (ojdbc6.jar)-Treibern unterstützt wird.

  Wenn Sie eine ROWID-Pseudospalte zu einer Abfrage hinzufügen, können Sie diese in JDBC mit dem ResultSet getString-Einstiegspunkt abrufen. Sie können eine ROWID mit dem setString-Einstiegspunkt an einen preparedStatement-Parameter binden.

  Das ermöglicht In-Place-Updates wie im folgenden Beispiel:

  In der Klasse ResultSetMetaData werden Spalten, die ROWIDs enthalten, mit dem Typ oracle.jdbc.driver.OracleTypes.ROWID gemeldet, dessen Wert -8 ist.

• Wie unterstützen die JDBC-Treiber Oracle REFCURSOR-Datentypen?

  Der Oracle JDBC-Treiber unterstützt Bind-Variablen vom Typ REFCURSOR. Ein REFCURSOR wird durch ein JDBC-ResultSet repräsentiert. Nutzen Sie die Methode getCursor des CallableStatement, um einen REFCURSOR-Wert, der von einem PL/SQL-Block in ein ResultSet zurückgegeben wird, zu konvertieren. JDBC ermöglicht Ihnen das Aufrufen einer gespeicherten Prozedur, die eine Abfrage ausführt und eine Ergebnismenge zurückgibt. Wandeln Sie das entsprechende CallableStatement mit einem Cast zu oracle.jdbc.driver.OracleCallableStatement um, um die Methode getCursor zu verwenden.

• Funktioniert ANO mit JDBC-Treibern?

  Ab Version 9.2 unterstützen sowohl OCI- wie auch Thin-Treiber ANO.

  ANO funktioniert mit 8.0.X OCI-Treibern der Version 8.0.x und höher. Sie müssen jedoch über die aktuellen Patchsets für die Versionen 8.0.4, 8.0.5 und 8.0.6 verfügen, damit dieses Feature korrekt funktioniert.

  Hinweis: Es gibt einen bekannten Bug (Nr. 899424) in 8.1.5 und 8.1.6sdk. Wir verfügen zwar über einen Bugfix dafür, aber dieser wurde bisher noch nicht rückportiert und als Patch für alle vorherigen Versionen veröffentlicht. Bisher besteht dieser Bug nur bei den Versionen 8.1.5 und 8.1.6sdk.

  Der Bugfix ist bereits im Code von Version 8.1.6 enthalten. Sie benötigen also keinen Patch für die Version 8.1.6 – der Code sollte einwandfrei funktionieren! Siehe für weitere Informationen auch Bug Nr. 899424.

• Kann ich oracle.sql.*-Datentypen serialisieren?

  Ja. Alle oracle.sql.*-Klassen, die SQL-Datentypen darstellen, können serialisiert werden.

• Unterstützen die JDBC-Treiber Objekte oder Collections?

  Ja, die Oracle JDBC-Treiber unterstützen Objekte und Collections. Dies ist der Fall seit Version 8.1.5.

• Kann ich WaitOption und AutoRollback verwenden?

  Die Rollback-Optionen WaitOption und AutoRollback für Batching-Aufrufe sind veraltet und stehen nicht länger zur Verfügung. Die folgenden Methoden können nicht länger verwendet werden.

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

• Kann eine gespeicherte Java-Prozedur in einer Datenbankinstanz eine Verbindung zu einer anderen Datenbankinstanz öffnen?

  Ja, wenn Sie den Thin-Servertreiber verwenden. Dies wird seit der Version 8.1.6sdk unterstützt.

  Der derzeit einzige bekannte Workaround ist die erste Installation so zu konfigurieren, dass sie DBLINKS verwendet, wenn die zweite Installation kontaktiert wird. Dadurch wird dem JDBC-Treiber suggeriert, dass er immer noch in derselben Instanz operiert. Dabei kümmert sich DBLINKS um die Details. Allerdings haben wir von Problemen gehört, die auftreten, wenn DBLINKS auf einer MTS-Serverinstallation verwendet wird.

• Was ist schneller, der Thin-Treiber oder der OCI-Treiber?

  Wie immer kommt es darauf an. Bei einigen Anwendungen ist der Thin-Treiber schneller, bei anderen der OCI-Treiber. Seit Version 10.1.0 ist der Thin-Treiber wahrscheinlich etwas schneller als der OCI-Treiber. Wenn Client und Server vom selben Hardwaretyp sind und dasselbe Betriebssystem aufweisen, nimmt der OCI-Treiber das RDBMS etwas weniger in Anspruch, auch wenn der Thin-Client schneller ist. Die Unterschiede sind üblicherweise gering – weniger als 10 %. Die meisten unserer Kunden verwenden den Thin-Treiber, da seine Administration einfacher ist. Der Nutzen, den Sie daraus ziehen können, kann unterschiedlich ausfallen.

• Was ist schneller, Anweisungen oder PreparedStatements?

  Anweisungen sind möglicherweise etwas schneller, wenn Sie die SQL nur einmal ausführen. PreparedStatements sind weitaus schneller, wenn die SQL mehr als einmal ausgeführt wird. Wenn Sie den Anweisungs-Cache verwenden, was wir Ihnen empfehlen, ist das Abrufen der Anweisung aus dem Cache gleichbedeutend mit der Ausführung derselben Anweisung.

  Im Allgemeinen wird dringend empfohlen, PreparedStatements zu verwenden. Das ist insbesondere dann der Fall, wenn Sie von Benutzern bereitgestellte Daten in der SQL versenden. Durch das Binding von Daten an einen PreparedStatement-Parameter können Sie die meisten SQL-Injection-Angriffe verhindern. Jeder Performance-Vorteil durch die Verwendung von Anweisungen ist vernachlässigbar.

• Wie verwende ich java.util.logging, um Trace-Ausgaben aus den Oracle JDBC-Treibern abzurufen?

  Zunächst müssen Sie eine JAR-Datei verwenden, die Logging-Code enthält. Der JDBC-Treiber ojdbc8.jar enthält keinerlei Logging-Code. Die Non-Debug-DMS-JAR-Datei ojdbc8dms.jar beinhaltet einigen Logging-Code. Die Debug-JAR-Dateien *_g.jar enthalten umfangreichen Logging-Code. Stellen Sie sicher, dass keine zusätzlichen Oracle JDBC-JAR-Dateien in Ihrem Classpath sind.

  Desweiteren müssen Sie Oracle JDBC-Logging aktivieren. Sie können das Logging global aktivieren, indem Sie eine Systemeigenschaft -Doracle.jdbc.Trace=true festlegen oder Sie können es programmatisch mit der Oracle JDBC Diagnosibility MBean steuern.

  // Namen erstellen
javax.management.ObjectName name = new javax.management.ObjectName("com.oracle.jdbc:type=diagnosibility,name=*");
// MBean-Server abrufen
javax.management.MBeanServer mbs = java.lang.management.ManagementFactory.getPlatformMBeanServer();
// herausfinden, ob Logging aktiviert ist oder nicht
System.out.println("LoggingEnabled = " + mbs.getAttribute(name, "LoggingEnabled"));
// Logging aktivieren
mbs.setAttribute(name, new javax.management.Attribute("LoggingEnabled", true));
// Logging deaktivieren
mbs.setAttribute(name, new javax.management.Attribute("LoggingEnabled", false));

  Das Aktivieren des Loggings allein führt nur zu minimalen Ausgaben. Für detailliertere und gezieltere Ausgaben müssen Sie java.util.logging konfigurieren.

• Wie konfiguriere ich java.util.logging, um von Oracle JDBC nützliche Trace-Ausgaben zu erhalten?

  Der JDBC-Code erstellt eine Reihe von Loggern. Um interessante Ausgaben zu erhalten, müssen Sie logLevel bei jedem dieser Logger festlegen und irgendwo einen Handler hinzufügen. Weitere Informationen dazu finden Sie im JavaDoc zu java.util.logging.

  Sie können aber auch die praktische Eigenschaftsdatei OracleLog.properties in der demo.zip-Datei verwenden, die Teil der Oracle JDBC-Treiberinstallation ist. Die Kommentare in dieser Datei erläutern, wie sie verwendet wird. Diese Lösung ist wesentlich einfacher und wird daher besonders empfohlen.

  Beachten Sie, dass Sie in beiden Fällen immer noch das Logging aktivieren müssen, um Trace-Ausgaben zu erhalten. Sie können die Trace-Ausgaben aktivieren und deaktivieren, ohne die Logger neu konfigurieren zu müssen. Das Diagnosibility MBean hat keinerlei Auswirkungen auf die Logger. Wenn Sie zum Aufrufen des MBean die Quelle nicht ändern möchten, können Sie -Doracle.jdbc.Trace=true zu Ihrem Java-Ausführungsbefehl hinzufügen. Dadurch wird die gesamte Ausführung protokolliert.

  Weitere Informationen zur Konfiguration des JDBC-Logging finden Sie im Whitepaper zum JDBC-Logging. Noch ein paar Hinweise: Das Setzen des Levels auf INFO protokolliert die SQL, die gerade ausgeführt wird, das Setzen auf FINE protokolliert Eingang und Ausgang aller öffentlichen Methoden, eine Einstellung von mehr als FINE aber wird Ihren ganzen Speicherplatz mit Logdateien belegen. Seien Sie also gewarnt.

• Was ist mit dem serverseitigen internen Treiber?

  Der serverseitige interne Treiber verwendet  java.util.logging für Trace-Ausgaben. Sie können die praktische

  Datei OracleLog.properties im Server verwenden, indem Sie folgendes ausführen:

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

  Verschieben Sie OracleLog.properties nach $ORACLE_HOME.