Aktualisiert am 5. Januar 2022
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-Referenzhandbuch und Javadoc für JDBC durch, um weitere Informationen zu erhalten.
Der folgende Abschnitt hebt die wichtigsten JDBC-Funktionen von Version 19c hervor. Ziehen Sie bitte Performance und Skalierbarkeit von Java-Anwendungen, die RDBMS verwenden zu Rate, um weitere Einzelheiten zu erfahren.
Aktuelle Java-Standards: Unterstützt JDK17, JDK11, JDK8 und ist kompatibel mit JDBC 4.3 (ojdbc11.jar und ojdbc10.jar) und JDBC 4.2(ojdbc8.jar) durch JDBC driver und Universal Connection Pool (ucp.jar)
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.
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
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 .
Ein guter Anfang ist die Java-Seite von Oracle.
Außerdem gibt es zahlreiche Bücher zu Java. Einige besonders beliebte davon sind:
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 4 der Lifetime Support-Richtlinie nachzusehen.
Freigeben | GA-Datum | Premier Support endet | Erweiterter Support endet | Sustaining Support endet |
---|---|---|---|---|
21c (Innovations-Version) | Aug. 2021 | Apr. 2024 | Nicht verfügbar | Unbegrenzt |
19c (Langfristige Version) | Apr. 2019 | Apr. 2024 | Apr. 2027 | Unbegrenzt |
18c | Jul. 2018 | Jun. 2021 | Nicht verfügbar | Unbegrenzt |
12,2 | Mär. 2017 | 30. Nov. 2020 (Begrenzter Zeitraum zur Fehlerkorrekturfür 12.2.0.1 – 1. Dez. 2020–31. März 2022) | Nicht verfügbar | Unbegrenzt |
EE 12.1 | Jun. 2013 | Jul. 2018 | Jul. 2022 | Unbegrenzt |
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.
Interoperabilitätsmatrix | Datenbank 23.3 | Database 21.x | Database 19.x | Datenbank 18.3 | Database 12.2 und 12.1 |
---|---|---|---|---|---|
JDBC 23.3 | Ja | Ja | Ja | Nein | Nein |
JDBC 21.x | Ja | Ja | Ja | Vorher | Vorher |
JDBC 19.x | Ja | Ja | Ja | Vorher | Vorher |
JDBC 18.x | Nein | Vorher | Vorher | Vorher | Vorher |
JDBC 12.2 und 12.1 | Nein | Vorher | Vorher | Vorher | Vorher |
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.
Version von Oracle Database | Für die Version spezifische JDBC -JAR-Dateien |
---|---|
23.x | ojdbc11.jar bei JDK11, JDK17, JDK19 und JDK21 ojdbc8.jar bei JDK8 und JDK11 |
21.x | ojdbc11.jar bei JDK11, JDK17 und JDK19 ojdbc8.jar bei JDK8 und JDK11 |
19.x | ojdbc10.jar bei JDK11 und JDK17 ojdbc8.jar bei JDK8, JDK11, JDK17 und JDK19 |
18.x | ojdbc8.jar bei JDK8 und JDK11 |
12.2 oder 12cR2 | ojdbc8.jar bei JDK 8 |
12.1 oder 12cR1 | ojdbc7.jar bei JDK 7 und JDK 8 ojdbc6.jar bei JDK 6 |
11.2 oder 11gR2 | ojdbc6.jar bei JDK 6, JDK 7 und JDK 8 (Hinweis: JDK7 und JDK8 werden nur in 11.2.0.3 und 11.2.0.4 unterstützt) ojdbc5.jar bei JDK 5 |
Die Tabelle führt die Oracle JDBC-Treiber auf und welche JBDC-Spezifikationen in dieser bestimmten Version unterstützt werden.
Version von Oracle Database | Compliance der JDBC-Spezifikationen |
---|---|
23.x und 21.x | JDBC 4.3 bei ojdbc11.jar JDBC 4.2 bei ojdbc8.jar |
19.x | JDBC 4.3 bei ojdbc10.jar JDBC 4.2 bei ojdbc8.jar |
18.3 | JDBC 4.2 bei ojdbc8.jar |
12.2 oder 12cR2 | JDBC 4.2 bei ojdbc8.jar |
12.1 oder 12cR1 | JDBC 4.1 bei ojdbc7.jar JDBC 4.0 bei ojdbc6.jar |
11.2 oder 11gR2 | JDBC 4.0 bei ojdbc6.jar JDBC 3.0 bei ojdbc5.jar |
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.
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
Connection conn = DriverManager.getConnection(. . .); conn.beginRequest(); // funktioniert, da beginRequest in Java 10 enthalten ist ((OracleConnection)conn).beginRequest(); // funktioniert, da OracleConnection JDBC 4.3 (in Java 10) unterstützt und beginRequest Teil von JDBC 4.3 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.
Laden Sie bitte die erforderliche JDBC-JAR und andere zugehörige JARs wie orai18n.jar, oraclepki.jar, osdt_core.jar, osdt_cert.jar
von der JDBC-Download-Seite des Oracle Technology Network herunter.
Ziehen Sie bitte die untenstehende Tabelle zu Rate, um weitere Einzelheiten zu den JDBC-Treibern zu erfahren.
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.
Aufgrund der Verwendung nativer Methoden ist der JDBC-OCI-Treiber plattformspezifisch. Oracle unterstützt Solaris, Windows und viele andere Plattformen.
Dieser JDBC-OCI-Treiber ist für die Installation mit der OCI Instant Client-Funktion verfügbar, die keine komplette Installation des Oracle-Client erfordert. Weitere Informationen finden Sie unter Oracle Call Interface.
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.
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 unter InternalT2Driver.java und InternalT4Driver.java.
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.
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.
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. Schauen Sie sich Wozu dienen die verschiedenen JAR-Dateien auf der Downloadseite? an, um zu bestimmen, welche Dateien Sie benötigen.
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.
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. See Kann ich eine der Klassendateien in die Oracle Server Java VM laden?
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);
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:
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.
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.
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.
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
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.
OracleDriver
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.
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()
gibt, 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.
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.
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.
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“.
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:
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");
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.
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.
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.
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.
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 Verbindungseigenschaft disableDefineColumnType
auf„true“
setzen. Dadurch wird defineColumnType
zu einem NOOP. Stellen Sie diese Verbindungseigenschaft nicht ein 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.
defineColumnType
auf dem Server Konvertierungen?Nicht beim Thin-Treiber, aber bei den OCI- und serverseitigen internen Treibern.
Benutzen Sie die Eigenschaft ‚CONNECTION_PROPERTY_PROCESS_ESCAPES‘ in OracleConnection.
Ja. Siehe dazu das 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. Schauen 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.
Allgemein ist jeder setXXX-Methode ein fester Datentyp zugeordnet, der dem Argumenttyp am sinnvollsten entspricht.
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.
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.
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.
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.
Form | Anweisung | Treiber | Untere Grenze | Obere Grenze | Bind-Mechanismus | Hinweis |
---|---|---|---|---|---|---|
Alle | Alle | Alle | 0 | 0 | Null | |
Alle | SQL | Client | 1 Zeichen | 32.766 Zeichen | Direkt- | |
Alle | SQL | Client | 32.767 Zeichen | 2.147.483.647 Byte | Stream | |
Alle | SQL | Client | 2.147.483.648 Byte | 2.147.483.647 Zeichen | Temp. CLOB | |
ZEICHEN | Server | 1 Zeichen | 65.536 Byte | Direkt- | 1, 2 | |
NCHAR | 1 Zeichen | 4.000 Byte | Direkt- | |||
NCHAR | 4.001 Byte | 2.147.483.647 Zeichen | Temp. CLOB | |||
ZEICHEN | 65.537 Byte | 2.147.483.647 Byte | Stream | |||
2.147.483.647 Byte | 2.147.483.647 Zeichen | Temp. CLOB | ||||
Alle | PL/SQL | Alle | 1 Zeichen | 32.512 Zeichen | Direkt- | |
Alle | PL/SQL | Alle | 32.513 Zeichen | 2.147.483.647 Zeichen | Temp. CLOB |
Anweisung | Treiber | Untere Grenze | Obere Grenze | Bind-Mechanismus | Hinweis | |
---|---|---|---|---|---|---|
Alle | Alle | Alle | 0 | 0 | Null | |
Alle | SQL | Client | 1 Zeichen | 32.766 Zeichen | Direkt- | |
Alle | SQL | Client | 32.767 Zeichen | 2.147.483.647 Byte | Stream | |
Alle | SQL | Client | 2.147.483.648 Byte | 2.147.483.647 Zeichen | Temp. CLOB | |
ZEICHEN | Server | 1 Zeichen | 65.536 Byte | Direkt- | 1, 2 | |
NCHAR | 1 Zeichen | 4.000 Byte | Direkt- | |||
NCHAR | 4.001 Byte | 2.147.483.647 Zeichen | Temp. CLOB | |||
ZEICHEN | 65.537 Byte | 2.147.483.647 Byte | Stream | |||
2.147.483.647 Byte | 2.147.483.647 Zeichen | Temp. CLOB | ||||
Alle | PL/SQL | Alle | 1 Zeichen | 32.512 Zeichen | Direkt- | |
Alle | PL/SQL | Alle | 32.513 Zeichen | 2.147.483.647 Zeichen | Temp. CLOB |
Hinweise:
können ersetzt werden durch
begin Insert into blob_tab (blob_col) values (? ); end;
API | FORM | Anweisung | Treiber | Untere Grenze | Obere Grenze | Bind-Mechanismus | Hinweis |
---|---|---|---|---|---|---|---|
setBytesForBlob | n/a | Alle | Alle | 0 | 0 | Null | |
Alle | Client | 1 Byte | 2.000 Byte | Direkt- | |||
Alle | Client | 2.001 Byte | 21.474.836.487 Byte | Temp. BLOB | 2 | ||
setStringForClob | Alle | Alle | Alle | 0 | 0 | Null | |
Alle | Alle | Client | 1 Zeichen | 32.766 Zeichen | Direkt- | ||
Alle | Alle | Client | 32.767 Zeichen | 2.147.483.647 Zeichen | Temp. CLOB | ||
Alle | Alle | Server | 1 Zeichen | 4.000 Byte | Direkt- | ||
Alle | Alle | Server | 4.001 Byte | 2.147.483.647 Zeichen | Temp. CLOB | 1 |
Hinweise:
Ja.
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.
Ja. Beachten Sie, dass dies in Ihrem PL/SQL-Code ausgenutzt werden kann.
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.
Ja, sie werden nach der nächsten Ausführung der Anweisung oder beim Schließen der Anweisung freigegeben.
Ja. Abgesehen von der Entscheidung bei den größten Zeichenfolgen auf CLOB zu wechseln, die auf der Grundlage der angenommenen maximalen Größe erfolgt.
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.
Absolut! Die LOB-APIs ermöglichen einen wahlfreien Zugriff auf jeden Teil des LOB. Überlegen Sie, wo die jeweilige Verwendung angemessen wäre.
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.
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);
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(); }
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
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
zugeordnent 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:
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.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?).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.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
in Ihrer java
-Befehlszeile.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 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.
Methode | Spaltentyp | Maximale Länge |
---|---|---|
setBytes |
LONG |
4 KB |
setBytes |
LONG RAW |
2 GB |
setString |
LONG |
32.000 Zeichen (SetBigStringTryClob="false" )4.000 Zeichen ( SetBigStringTryClob="true" ) |
setString |
CLOB |
2 GB Zeichen |
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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);
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.
Die Eigenschaften eines Beans können wie folgt klassifiziert werden:
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.
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.
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.
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.
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.
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“.
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“.
Sie verwenden den OCI8-Treiber bei einer Oracle7-Client-Installation. Verwenden Sie stattdessen den OCI17-Treiber.
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 eine Zeitlang vermeiden, indem Sie einfach den Grenzwert von „OPEN_CURSORS“ erhöhen. Aber dadurch wird das Problem nur verdeckt, nicht behoben. Es liegt in Ihrer Verantwortung, Cursor, die Sie nicht länger benötigen, zu schließen.
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.
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.
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.
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\"");
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.
Ü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.
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
Ja. Schauen Sie in $ORACLE_HOME/jdbc/demo/demo.tar
auf UNIX-Systemen und in $ORACLE_HOME/jdbc/demo/demo.zip
auf Windows-Systemen nach.
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.
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:
Samples-Readme.txt, Makefile,
und jeder .java-Datei.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.
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 deaktivieren, 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“.
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:
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.
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
Visual Cafe wird nicht mehr unterstützt.
Visual J++ wird nicht mehr unterstützt.
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:
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.
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.
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:
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;
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.
Wir unterstützen die getCursorName- und setCursorName-JDBC-Einstiegspunkte nicht. Stattdessen stellen wir Zugriff zu ROWIDs bereit, die eine ähnliche Funktionalität bieten. JDBC 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.
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.
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.
Ja. Alle oracle.sql.*
-Klassen, die SQL-Datentypen darstellen, können serialisiert werden.
Ja, die Oracle JDBC-Treiber unterstützen Objekte und Collections. Dies ist der Fall seit Version 8.1.5.
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();
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.
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.
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.
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.
// create name
javax.management.ObjectName name = new javax.management.ObjectName("com.oracle.jdbc:type=diagnosibility,name=*");
// get the MBean server
javax.management.MBeanServer mbs = java.lang.management.ManagementFactory.getPlatformMBeanServer();
// find out if logging is enabled or not
System.out.println("LoggingEnabled = " + mbs.getAttribute(name, "LoggingEnabled"));
// enable logging
mbs.setAttribute(name, new javax.management.Attribute("LoggingEnabled", true));
// disable logging
mbs.setAttribute(name, new javax.management.Attribute("LoggingEnabled", false));
Das Aktivieren des Loggings allein führt nur zu minimalen Ausgaben. Für detailliertere und gezieltere Ausgaben müssen Sie java.util.logging
konfigurieren.
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.
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
.