Actualizado el 5 de enero de 2022
Este documento responde a las preguntas más frecuentes sobre los controladores JDBC de Oracle. Tenga en cuenta que estas preguntas frecuentes sólo abordan cuestiones técnicas específicas y se utilizan para documentar soluciones a preguntas frecuentes de los clientes, así como cualquier problema conocido. Consulte la Guía de Referencia de JDBC yJavadoc para JDBC para obtener información más detallada.
La siguiente sección destaca las principales funciones de JDBC en la versión 19c. Consulte Revisión del desempeño y la escalabilidad de las aplicaciones Java que utilizan RDBMSes para obtener más detalles.
Últimos estándares Java: Admite JDK17, JDK11, JDK9 y JDK8, y es compatible con JDBC 4.3 (ojdbc11.jar y ojdbc10.jar) y JDBC 4.2(ojdbc8.jar) a través del controlador JDBC y Universal Connection Pool (ucp.jar)
Para los desarrolladores Java que utilizan controladores JDBC y/o UCP, las instrucciones detalladas para conectarse al servicio de base de datos en la nube están presentes en la página JDBC con DB Cloud .
La API de conectividad de bases de datos Java (JDBC) es el estándar del sector para la conectividad independiente de bases de datos entre el lenguaje de programación Java y una amplia gama de bases de datos: bases de datos SQL y otras fuentes de datos tabulares, como planillas o archivos planos. Proporciona una API de nivel de llamada para el acceso a bases de datos basadas en SQL.
La tecnología JDBC permite utilizar el lenguaje de programación Java para aprovechar las capacidades "escritura única, ejecución en cualquier lugar" de las aplicaciones que requieren acceso a datos empresariales. Con un controlador compatible con la tecnología JDBC, se puede conectar todos los datos corporativos incluso en un entorno heterogéneo.
-Consulte java.sql para ver el resumen de varias especificaciones JDBC (4.3, 4.2, 4.2, etc.,) resumen en JDK 11.
-Consulte las especificaciones de JDBC completas en jcp.org.
En la página de controladores JDBC de Oracle y obtener más información de la Guía para Desarrolladores JDBC y JDBC Github.
Existe mucha información sobre JDBC. Un buen punto de partida es JDBC API Tutorial and Reference, Tercera edición .
Un buen punto de partida es el sitio Java de Oracle.
Existe mucha información sobre Java. Algunos de los libros más populares son:
Consulte la siguiente tabla para conocer las versiones compatibles de los controladores JDBC. Tenga en cuenta que la información de esta tabla proporciona el resumen para su comodidad. Le recomendamos que consulte la página n.o 4 en Lifetime Support Policy para obtener más información y actualizaciones.
Versión | Fecha de disponibilidad general | Finaliza el soporte Premier | Finaliza el soporte Extendido | Finaliza el soporte de mantenimiento |
---|---|---|---|---|
21c (versión de innovación) | Agosto de 2021 | Abril de 2024 | No disponible | Indefinido |
19c (versión a largo plazo) | Abril de 2019 | Abril de 2024 | Abril de 2027 | Indefinido |
18c | Julio de 2018 | Junio de 2021 | No disponible | Indefinido |
12.2 | Marzo de 2017 | 30 de noviembre de 2020 (Limited Período de corrección de errores para 12.2.0.1 – 1 de diciembre de 2020 – 31 de marzo de 2022) | No disponible | Indefinido |
EE 12.1 | Junio de 2013 | Julio de 2018 | Julio de 2022 | Indefinido |
Consulte la tabla que abarca la matriz de interoperabilidad de controladores JDBC para las versiones de base de datos Oracle compatibles. La recomendación es que la versión del controlador JDBC sea siempre igual o superior a la versión de la base de datos Oracle para aprovechar las últimas capacidades del mismo.
Matriz de interoperabilidad | Database 23.3 | Database 21.x | Database 19.x | Database 18.3 | Database 12.2 y 12.1 |
---|---|---|---|---|---|
JDBC 23.3 | Sí | Sí | Sí | No | No |
JDBC 21.x | Sí | Sí | Sí | Antes | Antes |
JDBC 19.x | Sí | Sí | Sí | Antes | Antes |
JDBC 18.x | No | Antes | Antes | Antes | Antes |
JDBC 12.2 y 12.1 | No | Antes | Antes | Antes | Antes |
El controlador JDBC de Oracle siempre es compatible con la última versión de JDK de cada una de las nuevas versiones. En algunas versiones, los controladores JDBC admiten varias versiones de JDK. Utilice la siguiente tabla para seleccionar el controlador JDBC correcto según la versión de JDK que prefiera.
Versión de Oracle Database | Archivos Jar de JDBC específicos para la versión |
---|---|
23.x | ojdbc11.jar con JDK11, JDK17, JDK19 y JDK21 ojdbc8.jar con JDK8 y JDK11 |
21.x | ojdbc11.jar con JDK11, JDK17 y JDK19 ojdbc8.jar con JDK8 y JDK11 |
19.x | ojdbc10.jar con JDK11 y JDK17 ojdbc8.jar con JDK8, JDK11, JDK17 y JDK19 |
18.x | ojdbc8.jar con JDK8 y JDK 11 |
12.2 o 12cR2 | ojdbc8.jar con JDK 8 |
12.1 o 12cR1 | ojdbc7.jar con JDK 7 y JDK 8 ojdbc6.jar con JDK 6 |
11.2 o 11gR2 | ojdbc6.jar con JDK 6, JDK 7 y JDK 8 (Nota: JDK 7 y JDK 8 solo son compatibles en 11.2.0.3 y 11.2.0.4) ojdbc5.jar con JDK 5 |
La tabla enumera los controladores JDBC de Oracle y la especificación JDBC compatible en esa versión.
Versión de Oracle Database | Conformidad de las especificaciones de JDBC |
---|---|
23.x y 21.x | JDBC 4.3 en ojdbc11.jar JDBC 4.2 en ojdbc8.jar |
19.x | JDBC 4.3 en ojdbc10.jar JDBC 4.2 en ojdbc8.jar |
18.3 | JDBC 4.2 en ojdbc8.jar |
12.2 o 12cR2 | JDBC 4.2 en ojdbc8.jar |
12.1 o 12cR1 | JDBC 4.1 en ojdbc7.jar JDBC 4.0 en ojdbc6.jar |
11.2 o 11gR2 | JDBC 4.0 en ojdbc6.jar JDBC 3.0 en ojdbc5.jar |
Los controladores de Oracle JDBC solo están certificados con Oracle JVM (anteriormente Sun JVM). Sin embargo, los clientes han estado utilizando controladores de Oracle JDBC con JVM que no son de Oracle (por ejemplo, de IBM JVM). La única salvedad es que para que el equipo de desarrollo de Oracle JDBC y Oracle Support consideren un problema relacionado con los controladores Oracle JDBC, solicitaremos que dicho problema se reproduzca en Oracle JVM.
La versión 19.x tiene
(a) ojdbc8.jar (compilado con JDK 8 (JDBC 4.2) y se puede utilizar con JDK 9, JDK 11) y
(b) ojdbc10.jar (compilado con JDK 10 (JDBC 4.3) y se puede utilizar con JDK 11).
Si utiliza JDK 11, ojdbc8.jar sigue siendo la mejor opción, ya que incluye todas las funciones de la versión 4.3, pero como extensiones de Oracle. Los clientes pueden utilizar ojdbc10.jar sólo si necesitan funciones de JDBC 4.3 disponibles a través de Java SE estándar.
Ejemplo:
ojdbc8.jar:
Connection conn = DriverManager.getConnection(. . .); // conn.beginRequest(); fallaría porque beginRequest no está en Java 8 ((OracleConnection)conn).beginRequest(); // se realiza correctamente porque beginRequest se proporciona como una extensión de Oracle
Connection conn = DriverManager.getConnection(. . .); conn.beginRequest(); // se realiza correctamente porque beginRequest está en Java 10 ((OracleConnection)conn).beginRequest(); // se realiza correctamente porque OracleConnection es compatible con JDBC 4.3 (en Java 10) y beginRequest forma parte de JDBC 4.3
Si no aparece en la tabla anterior, consulte con el canal de soporte para comprobar si aún está en el contrato de soporte para las versiones anteriores.
Descargue el archivo jar de JDBC y otros archivos jar complementarios necesarios, como orai18n.jar, oraclepki.jar, osdt_core.jar, osdt_cert.jar
, en la página de descarga de JDBC de Oracle Technology Network.
Consulte la siguiente tabla para obtener más información sobre los controladores JDBC.
Oracle proporciona cuatro tipos diferentes de controladores JDBC para usar en diferentes implementaciones. Aunque todos los controladores JDBC de Oracle son similares, algunas funciones solo se aplican a los controladores JDBC OCI y otras solo se aplican al controlador JDBC Thin.
El uso de métodos nativos hace que la plataforma del controlador JDBC OCI sea específica. Oracle es compatible con Solaris, Windows y muchas otras plataformas.
Este controlador JDBC OCI está disponible para su instalación con la función OCI Instant Client, que no requiere una instalación completa de cliente de Oracle. Consulte Oracle Call Interface para obtener más información.
La mejor opción es utilizar el controlador JDBC Thin de Oracle. Las nuevas mejoras y funciones solo se implementan en el controlador JDBC Thin.
Si utiliza una red no TCP/IP, debe utilizar el controlador OCI.
Para el procesamiento in situ en la sesión de base de datos (es decir, Java en la base de datos), debe utilizar el controlador de tipo 2 incrustado (o el controlador interno del servidor); si el código java que se ejecuta en la sesión necesita acceder a una base de datos Oracle remota u otra sesión en la misma instancia de base de datos, debe utilizar el controlador de tipo 4 incrustado (o el controlador Thin del servidor).
Ambos controladores sólo se ejecutan en máquinas virtuales Oracle Java y sus clases se instalan como parte de la instalación de la máquina virtual. No hay archivos de clases independientes disponibles o necesarios para estos controladores. Consulte InternalT2Driver.java y InternalT4Driver.java como referencia.
Si se trata de una compañía de software de terceros (y partner de Oracle), consulte la licencia de FUTC y ejecútela por su departamento legal. A continuación, póngase en contacto con su representante de ventas de Oracle local para obtener más información.
Cuando la aplicación se ejecuta con una opción SecurityManager activada (que debería estar en producción), ciertas operaciones son privilegiadas. Para ralizarlas, el código debe disponer de los permisos adecuados.
La forma de saber qué permisos conceder es consultar el archivo ojdbc.policy en la página de descarga. Ae trata de un archivo de política de seguridad genérico que se puede utilizar para otorgar a los controladores todos los permisos necesarios. En la mayoría de los casos querrá comentar muchos de los permisos, ya que su aplicación no utiliza las funciones que requieren.
Este archivo depende de una serie de propiedades del sistema. Para utilizarlo, tendrá que definir esas propiedades mediante la opción -D del comando java
.
Algunos de los permisos solo se deben otorgar al código de controlador JDBC. Las operaciones que requieren esos permisos se incluyen en un bloque doPriviliged
. También se deben otorgar otros permisos al código que llama a los controladores. Estas operaciones no están entre bloques doPriviliged
. Un ejemplo digno de mención es que el código de llamada necesita el permiso de socket abierto cuando se utiliza el controlador thin para abrir una conexión. Es para evitar que el código no válido utilice los controladores para un ataque de denegación de servicio, entre otras razones.
Descargue el controlador JDBC de Oracle que es compatible con la versión de JDK que está utilizando. Es posible encontrar las últimas versiones del controlador JDBC en la página de descarga. Asegúrese de incluir los controladores JDBC en la classpath. Consulte ¿Cuáles son los diferentes archivos JAR de la página de descarga? para determinar qué archivos necesita.
El controlador JDBC OCI generalmente requiere una instalación de cliente de Oracle de la misma versión que el controlador. Sin embargo, está disponible con la función OCI Instant Client, que no requiere una instalación completa de cliente de Oracle. Consulte la documentación sobre la instalación de OCI Instant Client.
No lo instala. Estos dos controladores se instalan como parte de la instalación de la base de datos. Si la base de datos se instaló con soporte de Java, estos dos controladores ya vienen instalados. Consulte ¿Puedo cargar uno de los archivos de clases en la máquina virtual Java de Oracle Server?
La primera versión de JDBC especificaba el uso de la clase java.sql.DriverManager
para crear Conexiones. Ello resultó ser insuficientemente flexible y las versiones posteriores de la especificación JDBC definen una forma adicional de crear conexiones utilizando DataSources. Se recomienda utilizar DataSources.
DataSources ofrece una forma más flexible de crear conexiones. Fue diseñado para utilizarse con JNDI, pero no tiene que utilizar JNDI para utilizar DataSources. Puede realizar tareas distintas de crear nuevas conexiones. En concreto, puede implementar una caché de conexión. DataSources es ahora la forma preferida de crear una conexión.
La forma más sencilla de obtener una conexión de DataSource es la siguiente:
ds = new oracle.jdbc.pool.OracleDataSource();
ds.setURL(myURL);
conn = ds.getConnection(user, password);
Debe utilizar Universal Connection Pool (UCP). Este nuevo mecanismo de almacenamiento en caché de conexiones es independiente del controlador, el protocolo y la base de datos. Admite conexiones no JDBC y conexiones JDBC a bases de datos que no sean Oracle. Al utilizar los controladores JDBC de Oracle ofrece funciones avanzadas de Oracle, entre las que se incluyen:
La caché de conexión implícita de Oracle no es compatible. Tenga en cuenta que la caché de conexión antigua, OracleConnectionCacheImpl no era compatible en la versión 11.1.
El pool de conexiones JDBC OCI es para agrupar varias sesiones con estado con pocas conexiones físicas subyacentes a la base de datos. La conexión está vinculada a la sesión sólo mientras dure la llamada. El elemento de pool es la conexión física subyacente. Las sesiones de aplicación pueden migrar (internamente) a cualquier conexión física disponible subyacente.
Cada conexión física del pool tiene una sesión interna adicional en el servidor. Por lo tanto, se pueden ver más sesiones en el servidor.
En general el formato es
jdbc:oracle:<drivertype>:<username/password>@<database>
El <drivertype>
delgado
oci
kprb
El <username/password>
está vacío o fuera del formulario
<nombre de usuario>/<contraseña>
Tenga en cuenta que una URL como
tiene un nombre de usuario y una contraseña vacíos mientras que esta URL
jdbc:oracle:thin:@mydatabase
no especifica un nombre de usuario y una contraseña. Al utilizar este formulario, el nombre de usuario y la contraseña se deben proporcionar de otra forma.
La descripción de <database< depende en cierta medida del tipo de controlador. Si el tipo de controlador es kprb, la descripción de <database> estará vacía. Si el tipo de controlador es oci y desea utilizar una conexión bequeath, la <database> está vacía. De lo contrario (controlador thin
o oci
y no pulsar) la descripción de la base de datos es una de las siguientes:
//<host>:<port>/<service>
<host>:<port>:<SID>
<TNSName>
La siguiente URL conecta el usuario scott
con la contraseña tiger
a una base de datos con el servicio orcl
(Importante: consulte more on services) a través del puerto 1521 del host myhost usando el controlador Thin.
jdbc:oracle:thin:scott/tiger@//myhost:1521/orcl
Esta URL se conecta a la misma base de datos con el controlador OCI y SID
inst1 sin especificar el nombre de usuario o la contraseña.
jdbc:oracle:oci:@myhost:1521:inst1
Esta URL se conecta a la base de datos denominada GL en el archivo tnsnames.ora
con el controlador Thin y sin nombre de usuario ni contraseña especificados. El nombre de usuario y la contraseña se deben especificar en otro lugar.
jdbc:oracle:thin:@GL
El soporte para el uso de entradas TNSNAMES con el controlador Thin es nuevo en la versión 10.2.0.1.0. Para que esto funcione, debe haber configurado el archivo tnsnames.ora
correctamente
Además de la URL, utilice un objeto de la clase Java Properties
estándar como entrada. Por ejemplo:
java.util.Properties info = new java.util.Properties();
info.put ("user", "scott");
info.put ("password","tiger");
info.put ("defaultRowPrefetch","15");
getConnection ("jdbc:oracle:oci:@",info);
Todas las propiedades admitidas se definen en JavaDoc para oracle.jdbc.OracleConnection.
Hay constantes que definen los nombres de propiedad. JavaDoc para cada constante describe lo que hace la propiedad y cómo utilizarla.
En las versiones pre-11.1 del controlador, las propiedades se definen en JavaDoc para oracle.jdbc.pool.OracleDataSource.setConnectionProperties
y en la Guía del Desarrollador de JDBC Oracle.
OracleDriver
con DriverManager
?Ya no es necesario registrar la clase OracleDriver
para conectarse con el controlador interno del servidor, aunque no hay ningún inconveniente al hacerlo. Es así tanto si utiliza getConnection()
como defaultConnection()
para realizar la conexión.
Si utiliza ojdbc6.jar y JSE 6 o posterior, no es necesario registrar el controlador en absoluto, independientemente del controlador que esté utilizando. A partir de JSE 6, la interfaz de proveedor de servicios Java estándar registra los controladores automáticamente. Simplemente llame a DriverManager.getConnection
y el tiempo de ejecución encontrará el controlador y lo registrará.
Cualquier nombre de usuario o contraseña que incluya en la cadena de URL se ignora al conectarse a la conexión predeterminada del servidor. El método DriverManager.getConnection()
informa sobre un nuevo objeto Connection
de Java cada vez que lo llama. Tenga en cuenta que, aunque el método no está creando una nueva conexión de base de datos (solo se utiliza una única conexión implícita), informa sobre nuevo objeto java.sql.Connection.
De nuevo, cuando el código JDBC se está ejecutando dentro del servidor de destino, la conexión es un canal de datos implícito, no una instancia de conexión explícita como desde un cliente. Nunca debe cerrarse.
La solución es aumentar el tamaño de inicio (-ms) y el tamaño máximo (-mx) del pool de asignación de memoria. Esto debería ser menos problemático con los controladores 11.1 y posteriores, ya que utilizan menos memoria que los controladores 10g. Existe un análisis más detallado de este problema en el documento técnico "Gestión de memoria JDBC" de la página web de JDBC OTN.
Oracle está sustituyendo el mecanismo SID para identificar bases de datos por un nuevo enfoque de servicios. Está disponible en la base de datos desde 8.1.wi7. JDBC admite servicios en la URL de conexión. Alentamos encarecidamente a todos a pasar de los SID a los servicios lo antes posible, ya que los SID dejarán de recibir soporte en una de las próximas versiones de la base de datos.
El formato básico de una URL de servicio es:
jdbc:oracle:thin:[<user>/<password>]@//<host>[:<port>]/<service> jdbc:oracle:oci:[<user>/<password>]@//<host>[:<port>]/<service>
Ejemplos:
jdbc:oracle:thin:@//myserver.com/customer_db jdbc:oracle:oci:scott/tiger@//myserver.com:5521/customer_db
Para obtener más información, consulte la Guía del Usuario de JDBC.
La única forma de hacerlo es utilizar el objeto Propiedades al conectarse, en lugar de especificar el nombre de usuario y la contraseña como cadenas. Escriba el nombre de usuario en la propiedad "user" (usuario) y la contraseña en la propiedad "password" (contraseña). A continuación, ponga el modo en la propiedad "internal_logon". Algo similar a lo siguiente:
Properties props = new Properties();
props.put("user", "scott");
props.put("password", "tiger");
props.put("internal_logon", "sysoper");
Connection conn = DriverManager.getConnection (url, props);
Al conectarse como SYSDBA o SYSOPER a través el controlador Thin, RDBMS debe estar configurado para utilizar un archivo de contraseñas. Consulte "Creación y mantenimiento de un archivo de contraseñas" en la "Guía del administrador de Oracle Database".
Los controladores JDBC OCI admiten los mismos algoritmos que el servidor de base de datos.
En las versiones 11.1 y 11.2, el controlador JDBC Thin admite:
Si el servidor está configurado correctamente, utilice las siguientes propiedades de conexión:
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");
La autenticación de proxy es la capacidad de conectarse como usuario a través de otro usuario. Por ejemplo, la autenticación de proxy permite que el nivel medio se autentique una vez en la base de datos a través de una cuenta "genérica" y, a continuación, establezca una sesión ligera en nombre de usuarios reales. Consulte JavaDoc para oracle.jdbc.OracleConnection.openProxySession.
Sí, pero la compatibilidad es específica del controlador. El cifrado SSL se admite en el controlador JDBC-OCI desde Oracle JDBC 9.2.x, y en el controlador THIN a partir de la versión 10.2.
Sí. El controlador JDBC THIN admite LDAP y LDA a través de SSL normales en la URL de conexión, por ejemplo, al utilizar Oracle Internet Directory como proveedor LDAP. Para más detalles, consulte la Guía del desarrollador de Oracle JDBC y la Guía del administrador de Oracle Net Services.
Por lo general, se recomienda utilizar Oracle Connection Manager para crear un proxy de las conexiones a través del firewall. Se abre un puerto designado para que lo utilice Oracle Connection Manager y permite que maneje el resto. No debe abrir directamente ningún puerto que utilice el listener de base de datos, como el puerto 1521.
Consulte la guía del administrador de Oracle Net Services para obtener información sobre cómo configurar Oracle Connection Manager.
defineColumnType
y cuándo debo utilizarlo?defineColumnType
es una extensión JDBC de Oracle que proporciona un mayor desempeño en algunos casos. En versiones anteriores de JDBC Oracle, todos los controladores se beneficiaban de llamadas a defineColumnType
, pero a partir de la versión 10.1.0 el controlador Thin ya no necesita la información proporcionada. El controlador Thin logra el máximo desempeño sin llamadas a defineColumnType
. Los controladores internos de OCI y del servidor aún obtienen un mejor desempeño cuando la aplicación utiliza defineColumnType
.
Si el código se utiliza con los controladores Thin y OCI, se puede desactivar el método defineColumnType
al utilizar Thin definiendo la propiedad de conexión disableDefineColumnType
en "true"
. Ello hará que defineColumnType
sea NOOP. No defina esta propiedad de conexión o, de lo contrario, defínala en "false"
cuando utilice los controladores OCI o Interno del servidor.
El tipo de columna Definir también se puede utilizar para cambiar el tipo de datos. O para limitar el tamaño de los datos de longitud variable.
Hay una nueva variación de esto con un 4o parámetro para form_of_use.
defineColumnType
las conversiones en el servidor?No para el controlador Thin y sí para los controladores OCI y Server-Side Internal.
Utilice una propiedad 'CONNECTION_PROPERTY_PROCESS_ESCAPES' en OracleConnection.
Sí. Consulte JavaDoc para oracle.jdbc.OraclePreparedStatement
. Busque los métodos setXXXAtName
. Además, oracle.jdbc.OracleCallableStatement
admite el enlace de argumentos a procedimientos PL/SQL a través de nombres de argumentos formales. Consulte JavaDoc para conocer los métodos oracle.jdbc.OracleCallableStatement.setXXX(String, ...)
.
Es muy importante tener en cuenta que setXXX(String, XXX)
se vincula mediante el nombre de parámetro formal del procedimiento almacenado llamado. setXXXAtName(String, XXX)
se vincula mediante el nombre del parámetro de estilo de Oracle ( :foo
) en la cadena SQL que se está ejecutando. Son muy diferentes y pueden dar resultados muy diferentes.
Por lo general, hay un tipo de dato fijo asociado a cada método setXXX que es el tipo de dato que más sensiblemente corresponde al tipo de argumento.
Los datos se envían al servidor en el formato del tipo de datos supuesto y el servidor intenta convertirlos al tipo del parámetro de destino. Si no es posible realizar ninguna conversión, el servidor señala un error y el controlador lanza una SQLException en el momento de la ejecución.
En el caso de sentencias SQL, podríamos ir primero al servidor para obtener la información de tipo y, a continuación, realizar las conversiones, pero ello implicaría más trabajo. El código se optimiza para el caso común en el que el programador JDBC utiliza la API más adecuada para el tipo de columna.
Existen tres tipos de SQL de Oracle: RAW, LONG RAW y BLOB. Los datos RAW tienen una longitud limitada, se almacenan directamente en una columna y se transmiten al servidor en paquetes en línea. Los datos LONG RAW tienen un límite mucho mayor (2 GB), se almacenan a través de un mecanismo especial junto a la fila y se transmiten al servidor a través de un mecanismo de devolución de llamada en streaming. Los datos BLOB tienen una longitud efectivamente ilimitada, se almacenan por separado de la tabla con sólo un localizador lob almacenado, y se transmiten al servidor, son operaciones separadas antes de que el localizador se almacene en una columna de la tabla.
Para los datos en bytes, existen tres tipos de Oracle SQL: VARCHAR2, LONG y CLOB. Los datos VARCHAR2 tienen una longitud limitada, se almacenan directamente en una columna y se transmiten al servidor en paquetes en línea. Los datos LONG tienen un límite mucho mayor (2 GB), se almacenan a través de un mecanismo especial junto a la fila y se transmiten al servidor a través de un mecanismo de devolución de llamada en streaming. Los datos CLOB tienen una longitud efectivamente ilimitada, se almacenan por separado de la tabla con sólo un localizador lob almacenado, y se transmiten al servidor, son operaciones separadas antes de que el localizador se almacene en una columna de la tabla.
Formulario | Estado | Controlador | Límite inferior | Límite superior | Mecanismo de enlace | Nota |
---|---|---|---|---|---|---|
Todo | Todo | Todo | 0 | 0 | Nulo | |
Todo | SQL | Cliente | 1 caracter | 32766 caracteres | Directo | |
Todo | SQL | Cliente | 32767 caracteres | 2147483647 bytes | Stream | |
Todo | SQL | Cliente | 2147483648 bytes | 2147483647 caracteres | Clob temporal | |
CARACTER | Servidor | 1 caracter | 65536 bytes | Directo | 1, 2 | |
NCHAR | 1 caracter | 4000 bytes | Directo | |||
NCHAR | 4001 bytes | 2147483647 caracteres | Clob temporal | |||
CARACTER | 65537 bytes | 2147483647 bytes | Stream | |||
2147483647 bytes | 2147483647 caracteres | Clob temporal | ||||
Todo | PL/SQL | Todo | 1 caracter | 32512 caracteres | Directo | |
Todo | PL/SQL | Todo | 32513 caracteres | 2147483647 caracteres | Clob temporal |
Estado | Controlador | Límite inferior | Límite superior | Mecanismo de enlace | Nota | |
---|---|---|---|---|---|---|
Todo | Todo | Todo | 0 | 0 | Nulo | |
Todo | SQL | Cliente | 1 caracter | 32766 caracteres | Directo | |
Todo | SQL | Cliente | 32767 caracteres | 2147483647 bytes | Stream | |
Todo | SQL | Cliente | 2147483648 bytes | 2147483647 caracteres | Clob temporal | |
CARACTER | Servidor | 1 caracter | 65536 bytes | Directo | 1, 2 | |
NCHAR | 1 caracter | 4000 bytes | Directo | |||
NCHAR | 4001 bytes | 2147483647 caracteres | Clob temporal | |||
CARACTER | 65537 bytes | 2147483647 bytes | Stream | |||
2147483647 bytes | 2147483647 caracteres | Clob temporal | ||||
Todo | PL/SQL | Todo | 1 caracter | 32512 caracteres | Directo | |
Todo | PL/SQL | Todo | 32513 caracteres | 2147483647 caracteres | Clob temporal |
Notas:
podrían sustituirse por
empezar a insertar en los valores blob_tab (blob_col) (? ); finalizar;
API | FORMULARIO | Estado | Controlador | Límite inferior | Límite superior | Mecanismo de enlace | Nota |
---|---|---|---|---|---|---|---|
setBytesForBlob | n/d | Todo | Todo | 0 | 0 | Nulo | |
Todo | Cliente | 1 byte | 2000 bytes | Directo | |||
Todo | Cliente | 2001 bytes | 21474836487 bytes | Blob temporal | 2 | ||
setStringForClob | Todo | Todo | Todo | 0 | 0 | Nulo | |
Todo | Todo | Cliente | 1 caracter | 32766 caracteres | Directo | ||
Todo | Todo | Cliente | 32767 caracteres | 2147483647 caracteres | Clob temporal | ||
Todo | Todo | Servidor | 1 caracter | 4000 bytes | Directo | ||
Todo | Todo | Servidor | 4001 bytes | 2147483647 caracteres | Clob temporal | 1 |
Notas:
Sí.
CallableStatements
y los procedimientos con los parámetros IN OUT
?Es un requisito que los tipos de dato del parámetro IN y OUT sean los mismos. El cambio automático provocará conflictos a menos que el código de usuario también cambie el tipo en registerOutParameter. Un mejor enfoque es no utilizar parámetros IN OUT donde esto puede ser un problema. Para ello, cambie el procedimiento original y agregue un procedimiento envoltorio o bloque PL/SQL que utilice parámetros IN y OUT independientes.
Sí. Tenga en cuenta que esto se puede aprovechar en el código PL/SQL.
El código existente seguirá funcionando correctamente. Hay un cambio. Anteriormente, si una entrada superaba los límites de tamaño de la API utilizada, se producía una SQLException al llamar a la API setXXX. Ahora, la excepción se producirá en tiempo de ejecución, si es que se produce.
Sí, se liberan después de la siguiente ejecución de la sentencia o cuando esta se cierra.
Sí. Excepto por la decisión de cambiar a Clob para las cadenas más grandes que se realizan suponiendo el tamaño máximo.
Probablemente no sea una buena idea crear la cadena realmente enorme en primer lugar. Consulte la documentación de los proveedores de Java Virtual Machine para conocer los efectos que tienen los objetos muy grandes en el sistema de gestión de memoria Java.
LONG RAW
y LONG
están en desuso. ¿Por qué hay nuevos usos de las API de setXXXStream
?Las API de flujo no están en desuso. Ofrecen un mejor desempeño para algunas operaciones que las API de LOB y se conservarán.
¡Por supuesto! Las API de LOB permiten el acceso aleatorio a cualquier parte del LOB. Considere utilizarlas cuando corresponda.
select * from tab where id in (?, ?, ?, ...)
?El problema es que RDBMS no admite parámetros de enlace para los elementos de la cláusula IN. Se trata de una limitación de la base de datos, no del controlador.
Este error se produce si intenta utilizar ResultSet después de cerrarlo. También sucede si cierra la sentencia que ha creado ResultSet.
ResultSet rset = stmt.executeQuery ("seleccionar ROWID de EMP"); ... rset.close (); // o stmt.close (); rset.getString (1);
La especificación de JDBC original necesita que las conexiones, las sentencias y ResultSets se cierren cuando ya no se pueda acceder a ellas. Ello requiere el uso de finalizadores. Los finalizadores tienen una enorme penalización del desempeño en todos los aspectos de una aplicación que se ejecuta en una JVM con cualquier finalizador. Sun strong desaconseja su uso. El cierre automático requeriría el uso de finalizadores que serían malos para todos los clientes tanto si se basaban o no en el cierre automático. No se trata de una solución aceptable.
Hasta donde sabemos, ningún controlador JDBC de cualquier proveedor implementa o ha implementado el cierre automático por el motivo descrito anteriormente. Este requisito se eliminó de la especificación, aunque algunos restos de esa redacción aparecen en un par de lugares. También aparece en el tutorial de JDBC. El tutorial, aunque informativo y útil, no es definitivo. No se ha actualizado en años. La especificación JDBC 4.0 no requiere ningún cierre automático.
ResultSets, las sentencias y las conexiones ocupan todos los recursos del cliente y del servidor. Siempre que esos objetos estén abiertos, se asignarán los recursos asociados. Los recursos sólo se liberan cuando se cierran los objetos. Si no se cierra ResultSets, las sentencias y/o las conexiones, se perderán recursos y afectarán el desempeño de la aplicación.
Al cerrar una conexión se cierran todas las sentencias asociadas. Al cerrar una sentencia, se cierran todas las ResultSets asociadas. Por lo tanto, si está con una conexión, puede cerrarla y todas las sentencias y ResultSets se cerrarán. Ésta es una práctica de programación aceptable. Una mejor práctica es cerrar sentencias de forma explícita y ResultSets en bloques finales. Esto hace que su aplicación sea más sólida y menos propensa a perder recursos a medida que evoluciona para satisfacer los requisitos cambiantes.
PreparedStatement ps = null; ResultSet rs = null; pruebe { ps = conn.prepareStatement(sql); pruebe { rs = ps.executeQuery(); mientras que (rs.next()) { // process row } } finalmente { si (rs != null) rs.close(); } } finalmente { si (ps != null) ps.close(); }
DATE
y TIMESTAMP
?Esta sección se encuentra en los tipos de datos simples. :-)
Antes de la versión 9.2, los controladores JDBC de Oracle asignaron el tipo SQL DATE
a java.sql.Timestamp.
Esto tiene cierto sentido porque el tipo SQL DATE
de Oracle contiene información de fecha y hora como java.sql.Timestamp.
La asignación más obvia a java.sql.Date
fue algo problemática, ya que java.sql.Date
no incluye información de tiempo. También fue el caso en el que RDBMS no era compatible con el tipo SQL TIMESTAMP
, por lo que no había ningún problema con la asignación de DATE
a Timestamp
.
En 9.2, se añadió soporte TIMESTAMP
al RDBMS. La diferencia entre DATE
y TIMESTAMP
es que TIMESTAMP
incluye nanosegundos y DATE
no. Por lo tanto, a partir de la versión 9.2, DATE
se asigna a Date
y TIMESTAMP
se asigna a Timestamp
. Desafortunadamente, si confiaba en los valores DATE
para contener información de tiempo, hay un problema.
Existen varias maneras de abordar este problema en los controladores 9.2 a 10.2:
TIMESTAMP
en lugar de DATE
. Probablemente esto no sea posible casi nunca, pero es la mejor solución cuando lo es.defineColumnType
para definir las columnas como TIMESTAMP
en lugar de DATE
. Existen problemas con esto porque realmente no desea utilizar defineColumnType
a menos que tenga que hacerlo (consulte ¿Qué es defineColumnType
y cuándo debo utilizarlo?).getTimestamp
en lugar de getObject
. Se trata de una buena solución cuando es posible, sin embargo, muchas aplicaciones contienen código genérico que se basa en getObject
, por lo que no siempre es posible.V8Compatible
. Esto indica a los controladores JDBC que utilicen la asignación antigua en lugar de la nueva. Puede definir este indicador como una propiedad de conexión o como una propiedad del sistema. Puede definir la propiedad de conexión añadiéndola al objeto java.util.Properties
transferido a DriverManager.getConnection
o a OracleDataSource.setConnectionProperties
. Para definir la propiedad del sistema, incluya una opción -D
en la línea de comandos java
.Oracle JDBC 11.1 corrige este problema. A partir de esta versión, el controlador asigna las columnas SQL DATE a java.sql.Timestamp
de forma pretedermindada. No es necesario definir V8Compatible
para obtener la asignación correcta. V8Compatible está fuertemente en desuso. No debe usarlo en absoluto. Si lo configuras en verdadero, no dañará nada, pero deberá dejar de usarlo.
Aunque rara vez se utilizó de esa manera, V8Compatible
no existía para corregir el problema de DATE to Date, sino para admitir la compatibilidad con bases de datos 8i. Las bases de datos 8i (y anteriores) no admiten el tipo TIMESTAMP. La definición de V8Compatible
no sólo ha provocado que SQL DATE se asigne al registro de hora cuando se lee desde la base de datos, también ha provocado que todo Timestamps
se convierta en SQL DATE cuando se escribe en la base de datos. Dado que 8i ya no es compatible, los controladores JDBC 11.1 no admiten este modo de compatibilidad. Por este motivo, V8Compatible
no es compatible.
Como se ha mencionado anteriormente, los controladores 11.1 convierten de forma predeterminada SQL DATE en Timestamp
al leer de la base de datos. Esto siempre fue lo correcto y el cambio en 9i fue un error. Los controladores 11.1 han vuelto al comportamiento correcto. Aunque no haya definido V8Compatible
en la aplicación, no debería ver ninguna diferencia en el comportamiento en la mayoría de los casos. Puede que observe una diferencia si utiliza getObject para leer una columna DATE
. El resultado será Timestamp
en lugar de Date
. Dado que Timestamp
es una subclase de Date
, generalmente no es un problema. Donde puede notar una diferencia es si se basa en la conversión de DATE
a date para truncar el componente de tiempo o si hace toString en el valor. De lo contrario, el cambio debe ser transparente.
Si por algún motivo su aplicación es muy sensible a este cambio y simplemente debe tener el comportamiento 9i-10g, hay una propiedad de conexión que puede establecer. Defina mapDateToTimestamp
en "false" y el controlador volverá al comportamiento predeterminado 9i-10g y asignará DATE a Date
.
Método | Tipo de columna | Longitud máxima |
---|---|---|
setBytes |
LONG |
4000 bytes |
setBytes |
LONG RAW |
2G bytes |
setString |
LONG |
32000 caracteres (SetBigStringTryClob="false" )4000 caracteres ( SetBigStringTryClob="true" ) |
setString |
CLOB |
Caracteres 2G |
En 9.2, setString() en LONG puede insertar hasta 64000 caracteres con el controlador OCI y 4000 caracteres con el controlador Thin. En 10.1.0, cambiamos el límite de ambos controladores a 32000 caracteres. Entendemos que reducir el límite de OCI de 64000 a 32 000 puede ser un problema para algunos clientes. Sin embargo, teniendo en cuenta la considerable mejora del desempeño que este cambio ha permitido y que Oracle recomienda encarecidamente a nuestros clientes que migren de LONG a CLOB, hemos decidido que el cambio arquitectónico es necesario.
Recomendamos a los clientes que necesiten setString() que trabajen con más de 32000 caracteres para migrar de LONG a CLOB.
TIMESTAMP WITH TIME ZONE
diferente?El comportamiento anterior era incorrecto. Véase el bug 4322830.
El comportamiento anterior era construir un Timestamp
que imprimiría el mismo valor que el valor de la base de datos. Sin embargo, dado que Timestamp
está en la zona horaria UTC, esto daría un valor Timestamp
que se compensó con el valor correcto. Las 8:00 a. m. del 1 de enero de 2007 UTC no es lo mismo que las 8:00 a. m. del 1 de enero de 2007 PST. Representan diferentes puntos en el tiempo.
Si lee las 8:00 a. m. del 1 de enero de 2007 PST en la base de datos, los controladores 9i y 10g crearían una Timestamp
con el valor 8:00 a. m. del 1 de enero de 2007 UTC. Este valor imprimiría "correctamente", es decir, se imprimiría como "8:00 a.m 1 de enero de 2007", pero obviamente representaba el instante incorrecto en el tiempo. Los controladores 11.1 corrigen este error.
JDBC 4.0 introdujo métodos de fábrica en la interfaz Connection
para crear instancias de ADT. Esta es una api mucho mejor que usar constructores. Recomendamos encarecidamente que utilice los métodos de fábrica en la medida de lo posible. Anularemos el uso de los constructores muy pronto y nos gustaría dejar de darles soporte lo antes posible.
Dado que los métodos de fábrica estándar se introducen en JDBC 4.0, esos métodos solo están disponibles en los controladores JSE 6 (ojdbc6.jar). Para crear tipos de propiedad de Oracle, los métodos de fábrica se definen en OracleConnection
para JSE 5 y JSE 6 (ojdbc5.jar y ojdbc6.jar). Una vez más, recomendamos encarecidamente que utilice los métodos de fábrica.
createArrayOf
?El tipo de matriz estándar SQL es anónimo, es decir, el tipo "array of foo" no tiene un nombre. Sólo se asigna un nombre al tipo de elemento. En Oracle SQL, se asigna un nombre al tipo de matriz. De hecho, los tipos de matriz anónima no están admitidos. Por lo tanto, el método de fábrica estándar JDBC 4.0 toma el tipo de elemento como su argumento y crea una instancia de un tipo de matriz anónima. Los controladores JDBC de Oracle definen un método propiedad de Oracle, createArray
, que toma el nombre de un tipo de matriz e informa una instancia de ese tipo de matriz con nombre. Ello es necesario en la forma en que se define Oracle SQL. Actualmente, la base de datos Oracle no admite el método createArrayOf
estándar JDBC 4.0.
Simplemente "elimina" un segmento del clob. *No* acorta el CLOB. Por lo tanto, la longitud del CLOB es la misma antes y después del ERASE. Puede utilizar DBMS_LOB.TRIM para reducir el CLOB.
Sí, pero debe asegurarse de que los argumentos de posición y longitud son correctos. También puede utilizar la interfaz OutputStream recomendada que, a su vez, llamará a putChars.
En JDBC los CLOB están *siempre* en USC2, que es el juego de caracteres de Oracle correspondiente al tipo "caracter" de Java. Por lo tanto, no hay equivalente para el CLOB de OCI CharSetId.
Depende. Al escribir valores pequeños, menos que 10000, LONG RAWs son más rápidos. Al escribir valores más grandes, la diferencia desaparece.
Este es el comportamiento correcto. Las columnas LONG no se 'recuperan' in situ (es decir, en fila). Se recuperan fuera de lugar y existen en el proceso hasta que se leen explícitamente. En este caso, hemos obtenido LobLocator (getBlob()) y, a continuación, estamos intentando obtener la longitud de este LOB antes de leer la columna LONG. Como el proceso no está claro, estamos obteniendo la excepción anterior. La solución sería completar la lectura de la columna Long antes de realizar cualquier operación en el BLOB.
Los LOB de Oracle utilizan semántica de valor. Al actualizar un LOB, debe volver a escribir el LOB en la base de datos para asegurarse de ver los cambios. Por razones técnicas, a veces los cambios se guardan aunque no escriba la línea de negocio, pero no se puede predecir cuándo ocurrirá, por lo que siempre debe escribir el LOB.
Que solía ser cierto, pero que ya no. REF ahora es serializable.
La siguiente nota puede seguir siendo valiosa si utiliza una versión anterior de los controladores JDBC de Oracle donde las REF no son serializables.
Los componentes importantes de la clase REF son la matriz de bytes que representa la referencia de objeto y el nombre totalmente cualificado del tipo de objeto. Puede utilizar una clase como la siguiente clase "SomeREF" para contener los bytes y el nombre de tipo de una REF de objeto. Esta clase es serializable. Puede volver a crear la REF con su método "toREF" que necesita una conexión JDBC como parámetro.
La clase pública SomeREF implanta java.io.Serializable { String typeName; byte[] bytes; public SomeREF (oracle.sql.REF ref) informa SQLException { this.typeName = ref.getBaseTypeName (); this.bytes = ref.getBytes (); } public oracle.sql.REF toREF (conexión) informa SQLException { informa nueva oracle.sql.REF (nuevo oracle.sql.StructDescriptor (typeName,conn),conn, bytes); } }
JDBC does not support creating new REF from scratch. JDBC no admite la creación de una nueva REF desde cero. Debe ir a la base de datos e insertar la nueva REF en SQL. A continuación, debe volver a seleccionar la REF e informarla al cliente.
Es más fácil hacerlo con un bloque PL/SQL. Por ejemplo, si dispone de las siguientes tablas:
crear o sustituir el punto de tipo como objeto (número x, número y); crear la tabla point_values_table de punto; crear la tabla point_ref_table (p punto de referencia); puede insertar un nuevo valor de punto en point_values_table, una nueva referencia en point_ref_table y devolver la referencia al cliente con el siguiente código: llamada oracle.jdbc.driver.OracleCallableStatement = (oracle.jdbc.driver.OracleCallableStatement) conn.prepareCall ("declare x REF point; " + "begin insert into point_values_table p values (point(10, 20))" + " return 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);
Los tipos de OPAQUE tienen datos binarios y métodos de soporte que se definen en una biblioteca de código nativa del servidor. Sólo están disponibles para uso interno de Oracle.
Las propiedades de un bean se pueden clasificar como:
Las propiedades de creación de objetos se deben definir antes de la creación del objeto, ya que son las propiedades clave para crearlo. Las propiedades de tiempo de ejecución se pueden definir en cualquier momento y modifican el comportamiento del bean en tiempo de ejecución.
La capacidad de desplazamiento, el nombre de usuario y la contraseña son todas las propiedades de creación de objetos. El estado de confirmación automática, recuento de recuperación previa y otros, son propiedades de tiempo de ejecución. Normalmente, el objeto en segundo plano cobra vida durante la ejecución/setCommand, por lo que todos los atributos de creación de sentencias se deben definir antes que eso. Puesto que se necesita un objeto de conexión para crear una URL de sentencia, se debe definir el nombre de usuario, la contraseña y otros necesarios para crear un objeto antes de definir el comando.
Sí, los flujos serializables permiten serializar el objeto de flujo en cualquier medio serializable como un archivo plano, conexión de red, etc. Esta función sólo se aplica a CachedRowSet. Es posible crear un CachedRowSet en una máquina en la que estén presentes los controladores Jdbc y, a continuación, moverlo a un cliente remoto donde sólo estén presentes los binarios de juego de filas y no los binarios de controlador. El cliente remoto puede modificar RowSet mediante la inserción, supresión o actualización. A continuación, vuelva a enviarlo al lugar donde están presentes los controladores Jdbc y los binarios RowSet para sincronizar los valores modificados en la base de datos.
Sí, se puede utilizar para desarrollar aplicaciones Java. A diferencia del controlador JDBC OCI, el controlador Thin sólo funciona con redes basadas en TCP/IP. Se recomienda a los usuarios que ejecutan aplicaciones en redes que no sean TCP/IP que utilicen el controlador JDBC OCI.
Debe utilizalo al acceder a la base de datos en un procedimiento almacenado de Java. Un procedimiento almacenado de Java es un método Java que se ejecuta dentro de Oracle RDBMS del mismo modo que PL/SQL se ejecuta en RDBMS. Puesto que se está ejecutando en RDBMS, se está ejecutando necesariamente en una sesión de base de datos. La conexión del controlador interno del servidor es el manejador de esa sesión de base de datos. Por lo tanto, si el código se está ejecutando en un procedimiento almacenado de Java y desea acceder a la base de datos, utilice el controlador interno del servidor, excepto en esas raras ocasiones en las que debe utilizar el controlador thin del servidor.
En un procedimiento almacenado en Java, normalmente debe utilizar el controlador interno del servidor. Se conecta a la misma sesión en la que se está ejecutando el procedimiento almacenado. Sin embargo, en ocasiones puede que desee conectarse a otra base de datos o a una nueva sesión en la misma base de datos. En cualquiera de estos dos casos, debe utilizar el controlador thin del servidor.
Asegúrese de que el controlador está registrado y de que utiliza una URL de conexión coherente con el controlador JDBC. Consulte Uso de Controladores JDBC de Oracle para conocer los valores correctos.
Al utilizar Win NT o Win95, Java Virtual Machine se queja de que no puede cargar OCI73JDBC.DLL, cuando no se puede cargar una de las DLL llamadas por OCI73JDBC.DLL. Los controladores JDBC OCI utilizan bibliotecas compartidas que contienen las partes de código C del controlador. La biblioteca es OCI73JDBC.DLL para el programa cliente Oracle7. La biblioteca compartida se instala normalmente en [ORACLE_HOME]\BIN al instalar el controlador JDBC de la distribución. Asegúrese de que el directorio está en su ruta. Consulte la sección de instalación de la documentación para obtener más información.
La biblioteca compartida también depende de otras bibliotecas. Si falta alguna de esas DLL, terminará con un error que indica que falta OCI73JDBC.DLL. JDBC OCI7 necesita los siguientes archivos Oracle7: CORE35.DLL, CORE35O.DLL, NLSRTL32.DLL y ORA73.DLL
La máquina virtual de Java (JavaSoft JDK) es JAVAI.DLL.
El tiempo de ejecución de Microsoft Visual C++ es MSVCRT.DLL, MSVCRTI.DLL, MSVCRT20.DLL y MSVCRT40.DLL.
Para encontrar la lista de DLL dependientes, vaya al programa Explorador de Windows, haga clic con el botón derecho en el DLL y seleccione Vista rápida. La pantalla Vista Rápida muestra, entre otras cosas, la tabla Import que muestra las DLL dependientes. Puede volver a instalar los archivos de soporte necesarios faltantes desde el CD de instalación de Oracle. Instale "Required Support Files 7.3.4", "SQL*Net Client 2.3.4" y "Oracle TCP/IP Protocol Adapter 2.3.4"c.
Está utilizando el controlador OCI8 en una instalación de cliente Oracle7. Utilice el controlador OCI7.
El número de cursores que un cliente puede abrir a la vez en una conexión es limitado (50 es el valor predeterminado). Debe cerrar explícitamente la sentencia mediante el método stmt.close() para cerrar y liberar los cursores.
Si no cierra estos cursores explícitamente, obtendrá este error con el tiempo. Simplemente aumentar el límite "OPEN_CURSORS" puede ayudarle a evitar el problema por un tiempo, pero eso sólo oculta el problema, no lo resuelve. Es su responsabilidad cerrar cursores de forma explícita que ya no necesite.
De forma predeterminada, una conexión JDBC tiene activado AutoCommit. Sin embargo, para utilizar un SQL que tenga 'para actualización', es necesario que autoCommit esté desactivado.
Por lo tanto, la solución es definir la confirmación automática en false.
Intente definir explícitamente NLS_LANG. Si NLS_LANG no está definido o está configurado correctamente, puede que el cliente no sea Oracle7.3.4. Instale Oracle7.3.4 en el cliente.
No hay ninguna instalación de Oracle en el cliente o la instalación no se ha realizado correctamente. Si aún no la ha hecho, utilice el CD de instalación normal del servidor de Oracle y realice una instalación de "cliente de Oracle" para colocar el software necesario en su máquina. Verifique si la instalación se ha realizado correctamente y, si es necesario, elimine y vuelva a instalar.
Tenga en cuenta que puede obtener este error al realizar una instalación de cliente y, luego olvidarse de definir ORACLE_HOME. Si no tiene la variable de entorno ORACLE_HOME, simplemente definirla o exportarla debe solucionar el problema, sin tener que volver a instalar el cliente.
El controlador JDBC Thin necesita comillas dobles alrededor de literales que contienen caracteres Unicode. Por ejemplo:
ResultSet rset = stmt.executeQuery ("select * from \"\u6d82\u6d85\u6886\u5384\"");
De forma predeterminada, el controlador confirma todas las sentencias INSERT y UPDATE tan pronto como ejecute la sentencia. Ello se conoce como modo autoCommit en JDBC. Puede obtener un mejor desempeño si desactiva autoCommit y utiliza sentencias de confirmación explícitas. Utilice el punto de entrada setAutoCommit de la clase Connection para desactivar autoCommit:
connection.setAutoCommit(false); consulte Batching Updates en la documentación de JDBC para obtener información sobre las extensiones de Oracle para las llamadas por lotes a INSERT y UPDATE. Al agrupar estos comandos se puede lograr incluso más velocidad que desactivando autoCommit.
Normalmente, este es el error que verá si el servidor se bloquea mientras está conectado a él. Es posible que esté estableciendo una conexión o que pueda estar a medio camino a través de una conexión establecida. De cualquier manera, debe verificar los archivos log del servidor para ver qué errores y volcados de pila se lanzaron en el servidor.
Tenga en cuenta que este error es diferente a lo que sucede si intenta conectarse a un puerto incorrecto/no válido o incluso a una máquina, obtendría un error diferente, no este. También es diferente al error que obtendría si el servidor no funciona y no acepta solicitudes de conexión.
El controlador Thin informa esta excepción cuando lee algo del RDBMS que no esperaba. Esto significa que el motor de protocolo en el controlador Thin y el motor de protocolo en RDBMS están fuera de sincronización. No hay forma de recuperarse de este error. La conexión está inactiva. Debe intentar cerrarlo, pero eso probablemente también fallará.
Si obtiene un caso de prueba reproducible que genera este error, envíe un TAR con el soporte global de Oracle. Asegúrese de especificar los números de versión exactos del controlador JDBC y RDBMS, incluidos los parches.
Sí. Busque en $ORACLE_HOME/jdbc/demo/demo.tar
en sistemas UNIX y en $ORACLE_HOME/jdbc/demo/demo.zip
en sistemas Windows.
Descomprima demo.tar
o demo.zip file.
Verá un archivo de ejemplo-Readme.txt. Lea primero este archivo para obtener una visión general de las demostraciones de JDBC y, a continuación, ejecute Makefile
en UNIX o llame a rundemo.bat
en Windows.
Las demostraciones de JDBC se deben ejecutar sin errores. Si obtiene un error que probablemente signifique un problema en la configuración. Verifique lo siguiente:
Samples-Readme.txt, Makefile,
y cada archivo .java para conocer los requisitos de las pruebas previas.Es una ayuda de depuración en tiempo de ejecución creada en versiones anteriores de Oracle JDBC. Cuando está activada, imprime mensajes sobre la ejecución del controlador JDBC de Oracle. Normalmente, estos mensajes incluyen entrada de método, valores de parámetros, estado interno significativo, errores internos, salida de método y valores de devolución.
A partir de la versión 10.1.0, la utilidad Oracle Trace solo es compatible en classes12_g.jar y classes12dms_g.jar. Todos los controladores JDBC de Oracle que admiten JDK 1.4 y posteriores utilizan la utilidad de rastreo incorporada en java.util.logging. Consulte la sección de java.util.logging para saber información sobre cómo obtener información de rastreo al utilizar JDBC 11, ojdbc14_g.jar o ojdbc14dms_g.jar.
Si tiene dificultades con la aplicación JDBC, puede que le resulte útil el rastreo. La mayoría de los mensajes se refieren a métodos JDBC internos y, por lo tanto, pueden ser oscuros. Aún así, puede obtener ayuda. Sugiero que defina el volumen de rastreo en 1 para empezar.
Si cree que hay un bug en JDBC, el rastreo puede ayudarnos a brindarle soporte. En este caso, deje el volumen de rastreo en el valor predeterminado. Debido a la gran salida que produce, tendrá que rastrear un pequeño caso de prueba o simplemente una parte limitada de una aplicación más grande. Asegúrese de incluir el código adecuado antes de la falla.
Consulte la sección de java.util.logging para saber sobre cómo obtener información de rastreo al utilizar JDBC 11.
Para utilizar la utilidad de rastreo de JDBC, debe usar un archivo jar de depuración: classes12_g.jar o classes12dms_g.jar. Si intenta utilizar el rastreo mientras utiliza uno de los otros archivos jar o zip, aparecerá un mensaje de error o ninguna salida.
Existen dos formas de controlar el rastreo: mediante programación o mediante propiedades. La API programática permite activar o desactivar el rastreo y cambiar otras propiedades mientras se ejecuta la aplicación. Dado el gran volumen de datos de rastreo, a menudo es una buena idea activarlo sólo para bits de código particularmente sospechosos. Si no es fácil cambiar el origen de la aplicación, puede controlarlo mediante propiedades. Estas propiedades se leen una vez al iniciar la aplicación y no se vuelven a leer. Puede utilizar las propiedades y la API al mismo tiempo. Las propiedades establecen el estado inicial y la api modifica dicho estado.
La forma más sencilla de activar el rastreo mediante programación es llamar
oracle.jdbc.driver.OracleLog.startLogging(); envía el rastreo a System.out. Para desactivar la llamada
oracle.jdbc.driver.OracleLog.stopLogging(); también puede activar el rastreo definiendo la propiedad del sistema oracle.jdbc.Trace
en "true".
java -Doracle.jdbc.Trace=true MyApp La configuración de cualquiera de las demás propiedades de la utilidad de rastreo de JDBC que se describen a continuación define implícitamente oracle.jdbc.Trace
en "true".
Consulte la sección de java.util.logging para saber sobre cómo obtener información de rastreo al utilizar JDBC 11.
La utilidad de rastreo JDBC puede producir una gran cantidad de salida. La forma más sencilla de controlar el volumen es activar sólo el rastreo cuando sea necesario.
oracle.jdbc.driver.OracleLog.startLogging(); envía el rastreo a System.out.
oracle.jdbc.driver.OracleLog.stopLogging(); a menudo esto no es posible. También puede reducir el número de mensajes de rastreo definiendo el volumen de rastreo. oracle.jdbc.driver.OracleLog.setLogVolume(1); el valor predeterminado es 2. El valor máximo es 3, pero actualmente no produce mucho más de 2. 1, es mucho menor que el valor predeterminado.
Puede controlar el tamaño de cada línea estableciendo un tamaño de línea explícito o cambiando los campos que se imprimen en cada línea. Para cambiar la longitud máxima de la línea
oracle.jdbc.driver.OracleLog.setMaxPrintBytes(100); o java -Doracle.jdbc.MaxPrintBytes=100 MyApp
Para controlar qué campos se imprimen, puede definir la propiedad oracle.jdbc.PrintFields.
java -Doracle.jdbc.PrintFields=none MyApp Los valores válidos son:
Consulte la sección de java.util.logging para saber sobre cómo obtener información de rastreo al utilizar JDBC 11.
De forma predeterminada, la salida de rastreo pasa a System.out.
Puede enviarlo a otro lugar con la propiedad oracle.jdbc.LogFile
java -Doracle.jdbc.LogFile=/tmp/jdbc.log MyApp o llamando a la API setLogStream. oracle.jdbc.driver.OracleLog.setLogStream(System.err); al definir el flujo de log también se inicia el rastreo. Es posible desactivar el rastreo definiendo el flujo de log en nulo.
Existe una propiedad del sistema oracle.dms.console.DMSConsole. Si esa propiedad no está definida, DMS está activo. Si se define en oracle.dms.instrument_stub.DMSConsole, se utiliza una implementación de stub, que desactiva DMS de forma eficaz. Una forma de desactivar una aplicación sería llamar
System.setProperty( "oracle.dms.console.DMSConsole", "oracle.dms.instrument_stub.DMSConsole"); antes de ejecutar cualquier código DMS. Otra forma sería utilizar la opción -D con Java VM. java -Doracle.dms.console.DMSConsole=oracle.dms.instrument_stub.DMSConsole MyApp
Visual Cafe ya no es compatible.
Visual J++ ya no es compatible.
Sí, tanto el controlador Oracle JDBC OCI como el controlador Thin JDBC admiten la ejecución de procedimientos almacenados PL/SQL y bloques anónimos. Admiten la sintaxis de escape SQL:2003 y la sintaxis de escape de Oracle. Las siguientes llamadas PL/SQL están disponibles en ambos controladores JDBC de Oracle:
Sí. Tanto el controlador Oracle JDBC OCI como el controlador Thin JDBC admiten la transmisión de datos en cualquier dirección entre el cliente y el servidor. Admiten todas las conversiones de flujos: binario, ASCII y Unicode. Para obtener más información, lea el tutorial de flujo en la documentación del controlador JDBC de Oracle.
Sí. Tanto el controlador Oracle JDBC OCI como el controlador Thin JDBC admiten juegos de caracteres multibyte: ambos pueden acceder a bases de datos que utilizan cualquier juego de caracteres de Oracle. Convierten caracteres multibyte en Unicode 1.2. El controlador JDBC OCI se ha probado y admite todos los juegos de caracteres europeos y asiáticos, incluidos chino, japonés y coreano.
Sí, tanto el controlador JDBC OCI como el controlador JDBC Thin pueden funcionar tanto en una intranet como en una configuración de Extranet. En una implementación de Extranet, los controladores se pueden utilizar con la mayoría de los firewalls líderes del sector que han recibido la certificación SQL*Net. Hoy en día, los siguientes proveedores de firewall han certificado sus firewalls con SQL*Net:
No No es posible que los controladores JDBC de Oracle admitan argumentos de llamada o valores de retorno de los tipos PL/SQL TABLE (ahora denominados tablas indexadas por), RESULT SET, RECORD o BOOLEAN. Actualmente no hay planes para cambiar esto. Se recomienda a las personas que utilicen RefCursor, Oracle Collections y tipos de objetos estructurados.
Como solución alternativa, se pueden crear procedimientos de envoltorio que gestionen los datos como tipos compatibles con JDBC.
Por ejemplo, para ajustar un procedimiento almacenado que utiliza booleanos PL/SQL, se puede crear un procedimiento almacenado que tome un caracter o número de JDBC y lo transfiera al procedimiento original como BOOLEAN o, un parámetro de salida, que acepte un argumento BOOLEAN del procedimiento original y lo transfiera como CHAR o NUMBER a JDBC. Del mismo modo, para ajustar un procedimiento almacenado que utilice registros PL/SQL, se puede crear un procedimiento almacenado que maneje un registro en sus componentes individuales (como CHAR y NUMBER). Para ajustar un procedimiento almacenado que utilice tablas PL/SQL, puede dividir los datos en componentes o quizás utilizar tipos de recopilación de Oracle.
A continuación, se muestra un ejemplo de un procedimiento de envoltorio PL/SQL MY_PROC para un procedimiento almacenado PROC que toma un BOOLEAN como entrada:
PROCEDIMIENTO MY_PROC (n NÚMERO) ES BEGIN IF n=0 THEN PROC(false); ELSE PROC(true); END IF; END; PROCEDIMIENTO PROCEDIMIENTO (b BOOLEAN) ES BEGIN ... END;
Sí. Al conectarse a un servidor RAC, Fast Connection Failover proporciona una respuesta rápida a los eventos de falla. Esta nueva función de alta disponibilidad es independiente del controlador y funciona junto con Implicit Connection Cache y RAC para proporcionar la máxima disponibilidad de conexiones en la caché. Esto se logra procesando los eventos inactivos de RAC para eliminar conexiones no válidas y eventos activos a fin de equilibrar la carga de conexiones existentes.
Si utiliza el controlador OCI y todo lo que necesita es un failover de consulta, puede considerar TAF. TAF facilita principalmente el failover de consultas en una aplicación. No se trata de un mecanismo de failover general. Tenga en cuenta que Fast Connection Failover y TAF no se pueden utilizar a la vez. Sólo se puede activar y utilizar uno a la vez.
No admitimos los puntos de entrada JDBC getCursorName y setCursorName. En su lugar, proporcionamos acceso a ROWIDs, que ofrecen una funcionalidad similar. JDBC 4.0 define java.sql.Rowid
, que es totalmente compatible con oracle.sql.ROWID
y está soportado en los controladores JSE 6 (ojdbc6.jar).
Si añade la pseudocolumna ROWID a una consulta, puede recuperarla en JDBC con el punto de entrada ResultSet getString. También puede vincular un ROWID a un parámetro preparedStatement con el punto de entrada setString.
Ello permite actualizaciones in situ, como en el siguiente ejemplo:
En la clase ResultSetMetaData, las columnas que contienen ROWID se notifican con el tipo oracle.jdbc.driver.OracleTypes.ROWID, cuyo valor es -8.
El controlador JDBC de Oracle admite variables de enlace de tipo REFCURSOR. Un REFCURSOR está representado por un JDBC ResultSet. Utilice el método getCursor de CallableStatement para convertir un valor REFCURSOR informado por un bloque PL/SQL en ResultSet. JDBC permite llamar a un procedimiento almacenado que ejecuta una consulta e informa un juego de resultados. Transfiera el CallableStatement correspondiente a oracle.jdbc.driver.OracleCallableStatement para utilizar el método getCursor.
A partir de la versión 9.2, los controladores OCI y Thin son compatibles con ANO.
ANO funciona con controladores OCI versión 8.0.x y superiores. Debe tener los últimos juegos de parches para 8.0.4, 8.0.5 y 8.0.6 para que este reucrso funcione correctamente.
Nota: Hay un bug conocido (#899424) en 8.1.5 y 8.1.6sdk. Aunque tenemos una corrección de bugs para esto, aún no se ha informado ni publicado como un parche en todas las versiones anteriores. Hasta ahora, este error aún existe para 8.1.5 y 8.1.6sdk.
La corrección del bug ya está en el código 8.1.6, por lo que no se necesita ninguna corrección parcial para la versión 8.1.6. ¡El código debería funcionar! Para obtener más información, consulte el bug #899424.
Sí. Todas las clases oracle.sql.*
que representan tipos de datos SQL se pueden serializar.
Sí, los controladores JDBC de Oracle admiten objetos y recopilaciones. Esto ha sido cierto desde la versión 8.1.5.
Las opciones de rollback WaitOption y AutoRollback para las llamadas por lotes están en desuso y ya no están disponibles. Ya no se pueden utilizar los siguientes métodos:
public void setAutoRollback (int autoRollback); public int getAutoRollback(); public void setWaitOption(int waitOption); public int getWaitOption();
Sí, con el controlador Thin-server. Esto es compatible desde 8.1.6sdk.
La única solución alternativa conocida en este momento es configurar la primera instalación para que utilice DBLINKS al ponerse en contacto con la segunda instalación. Esto hace que los controladores jdbc piensen que sigue funcionando en la misma instancia y depende de DBLINKS para cuidar los detalles. Sin embargo, se rumorea que hay problemas con el uso de DBLINKS en una instalación de servidor MTS.
Como siempre, depende. Hay algunas aplicaciones en las que el controlador Thin es más rápido, y otras en las que el controlador OCI es más rápido. A partir de la versión 10.1.0, el controlador Thin probablemente sea ligeramente más rápido que el controlador OCI. En los casos en los que el cliente y el servidor son del mismo tipo de hardware y sistema operativo, el controlador de OCI pone un poco menos de carga en el RDBMS, aunque el cliente Thin sea más rápido. Las diferencias suelen ser pequeñas, menos del 10%. La mayoría de nuestros clientes utilizan el controlador Thin debido a su administración más fácil. Su distancia recorrida puede variar.
Las sentencias pueden ser un poco más rápidas si sólo va a ejecutar el SQL una vez. PreparedStatements son mucho más rápidas cuando SQL se ejecutará más de una vez. Si utiliza la caché de sentencias, lo que debe hacer, obtener una sentencia de la caché, es lo mismo que ejecutar la misma sentencia.
En general, se recomienda utilizar PreparedStatements. Esto es especialmente cierto si envía datos proporcionados por el usuario en SQL. Al vincular los datos a un parámetro PreparedStatement, puede evitar la mayoría de los ataques de inyección SQL. Cualquier ventaja de desempeño del uso de sentencias es insignificante.
En primer lugar, debe utilizar un archivo jar que incluya el código de registro. El controlador JDBC ojdbc8.jar no incluye ningún código de registro. El archivo jar de DMS no de depuración, ojdbc8dms.jar, incluye algún código de registro. Los archivos jar de depuración, *_g.jar, incluyen un amplio código de registro. Asegúrese de que no hay archivos jar de Oracle JDBC adicionales en la classpath.
En segundo lugar, debe activar el registro de JDBC de Oracle. Se puede activar el registro globalmente definiendo una propiedad del sistema -Doracle.jdbc.Trace=true o controlarlo mediante programación con Oracle JDBC Diagnosibility MBean.
// create name
javax.management.ObjectName name = new javax.management.ObjectName("com.oracle.jdbc:type=diagnosibility,name=*");
// get the MBean server
javax.management.MBeanServer mbs = java.lang.management.ManagementFactory.getPlatformMBeanServer();
// find out if logging is enabled or not
System.out.println("LoggingEnabled = " + mbs.getAttribute(name, "LoggingEnabled"));
// enable logging
mbs.setAttribute(name, new javax.management.Attribute("LoggingEnabled", true));
// disable logging
mbs.setAttribute(name, new javax.management.Attribute("LoggingEnabled", false));
Sólo activar el registro proporciona una salida mínima. Para obtener una salida más detallada y dirigida, debe configurar java.util.logging
.
java.util.logging
para obtener una salida de rastreo útil de JDBC de Oracle?El código JDBC crea una serie de registradores. Para obtener una salida interesante, debe definir logLevel en cada uno de estos registradores y añadir un manejador en algún lugar. Para obtener más información, consulte JavaDoc para java.util.logging
.
O bien, puede utilizar el archivo de propiedades adecuado OracleLog.properties
proporcionado en el archivo demo.zip
que forma parte de la instalación de controladores JDBC de Oracle. Los comentarios de este archivo explican cómo utilizarlo. Es mucho más fácil y altamente recomendado.
Tenga en cuenta que en cualquier caso tiene que activar el registro para obtener la salida de rastreo. Puede activar y desactivar la salida de rastreo sin volver a configurar los registradores. El diagnóstico MBean no se interrumpe con los registradores. Si no desea cambiar el origen para llamar a MBean, puede añadir -Doracle.jdbc.Trace=true
al comando de ejecución java. Ello registrará toda la ejecución.
Para obtener más información sobre la configuración del registro JDBC, consulte el documento técnico sobre dicho registro. Un par de tips: al definir Level en INFO se registrará el SQL que se ejecuta, al definirlo en FINE se registrará la entrada y salida de todos los métodos públicos, al definirlo en algo más que FINE se rellenará todo el espacio en disco con archivos log. Téngalos en cuenta.
El controlador interno del servidor utiliza java.util.logging
para rastrear la salida. Puede utilizar lo conveniente
Archivo OracleLog.properties en el servidor ejecutando
System.setProperty("java.util.logging.config.file", "OracleLog.properties")
Escriba OracleLog.properties
en $ORACLE_HOME
.