Preguntas frecuentes

Abrir todo Cerrar todo
  • Novedades de la versión 19c

    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)

    • Conexión: Easy Connect Plus para facilitar las conexiones TCPS y pasar propiedades de conexión (sólo 19c); nuevo archivo ojdbc.properties para establecer propiedades de conexión; diferentes formas de configurar TNS_ADMIN; configurar el certificado de nombre de dominio (DN) del servidor como propiedad de conexión; y soporte de una nueva billetera de propiedad (my_wallet_directory);
    • Rendimiento: Reactive Streams Ingest (RSI) para transmitir datos a Oracle Database ( solo 21c); administrador de conexión (CMAN) de Oracle en modo director de tráfico (CMAN-TDM)
    • Alta disponibilidad: Continuidad de Aplicaciones Transparente (TAC); soporte de CA en DRCP; y soporte de CA para tipos JDBC anteriores de Oracle implementados como clases Java concretas.
    • Escalabilidad: afinidad de datos de Oracle RAC; y API de enrutamiento de fragmentos para niveles intermedios.
    • Seguridad: Resolución automática de proveedores para OraclePKIProvider; compatibilidad con Key Store Service (KSS); y compatibilidad con proxy HTTPS.
    • Tipos de datos: Accesibilidad a matrices asociadas PL/SQL; Oracle REF CURSOR como parámetro de enlace IN; y validación de tipos de datos JSON.
  • ¿Existen documentos relacionados con Oracle Database Cloud Service para desarrolladores Java?

    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 .

JDBC en General

Preguntas específicas sobre la versión

  • ¿Qué versión de los controladores JDBC son compatibles?

    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
  • ¿De qué se trata la matriz de interoperabilidad JDBC y RDBMS o la matriz de certificación?

    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 No No
    JDBC 21.x Antes Antes
    JDBC 19.x Antes Antes
    JDBC 18.x No Antes Antes Antes Antes
    JDBC 12.2 y 12.1 No Antes Antes Antes Antes
    Antes: era una combinación admitida, pero una de las versiones ya no está cubierta por Premier Support, Primary Error Correct Support, Extended Support o Extended Maintenance Support. Ya no es posible aplicar correcciones.
  • ¿Cuáles son las versiones de Oracle JDBC frente a las versiones de JDK?

    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
  • ¿Cuáles son las versiones de JDBC de Oracle frente a las especificaciones JDBC?

    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
  • ¿Están los controladores de Oracle JDBC certificados para OpenJDK?
     

    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.

  • ¿Cuál es el controlador JDBC 19.x recomendado para JDK 11?     

    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

    ojdbc10.jar:
    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
  • ¿Qué sucede con la versión de JDBC que no se muestra en la tabla anterior?

    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.

  • ¿Dónde puedo obtener los archivos jar de JDBC?

    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.

  • ¿Para qué sirven los distintos archivos JAR de la página de descarga del controlador JDBC 19.x?

    Consulte la siguiente tabla para obtener más información sobre los controladores JDBC.

    • ojdbc10-full.tar.gz: este archivo contiene el controlador JDBC Thin 19.x más reciente (ojdbc10.jar), Universal Connection Pool (ucp.jar), sus archivos Léame y archivos jar complementarios.
    • ojdbc8-full.tar.gz: este archivo contiene el controlador JDBC Thin 19.x más reciente (ojdbc8.jar), Universal Connection Pool (ucp.jar), sus archivos Léame y archivos jar complementarios.
    • ojdbc10.jar: certificado con JDK 11 y JDK 10, todas las clases son compatibles con la funcionalidad básica del controlador Thin. Se necesitan archivos jar adicionales al utilizar algunas funciones
    • ojdbc8.jar: certificado con JDK 9 y JDK 8, todas las clases son compatibles con la funcionalidad básica del controlador Thin. Se necesitan archivos jar adicionales al utilizar algunas funciones
    • ucp.jar: Universal Connection Pool (UCP) que proporciona las capacidades del pool de conexiones.
    • oraclepki.jar, osdt_core.jar y osdt_cert.jar: jar adicional necesario para acceder a carteras de Oracle desde Java
    • orai18n.jar: para que lo utilice el daemon de Oracle Notification Services (ONS)
    • simplefan.jar: API de Java para suscribirse a eventos RAC a través de ONS
    • xbd6.jar: clases para admitir la interfaz JDBC 4.x java.sql.SQLXML estándar
    • ojdbc8_g.jar: igual que ojdbc8.jar, excepto que se compila con la opción -g para incluir información de depuración y con llamadas java.util.logging incluidas.
    • ojdbc8dms.jar: igual que ojdbc8.jar, excepto que incluye código para admitir Oracle Dynamic Monitoring Service (DMS). También incluye algún soporte de registro JDBC. Este archivo sólo se puede utilizar cuando dms.jar también está en la classpath. El archivo dms.jar no se envía como parte del producto RDBMS. Solo está disponible como parte del producto Oracle Application Server.
    • ojdbc8dms_g.jar: igual que ojdbc8dms.jar excepto que se compila con la opción -g para incluir información de depuración y con soporte completo de registro JDBC.

Oracle JDBC en General

  • ¿Cuáles son los diferentes controladores JDBC que proporciona Oracle?

    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.

    • Controlador de cliente JDBC Thin: controlador JDBC Tipo 4 que utiliza Java para conectarse directamente a Oracle. Implementa los adaptadores SQL*Net Net8 y TTC de Oracle mediante su propia implementación de socket Java basada en TCP/IP. El controlador JDBC Thin no necesita que se instale el software de cliente de Oracle, pero sí que el servidor se configure con un listener TCP/IP. Recomendamos a todos nuestros clientes que utilicen el controlador JDBC Thin, ya que la mayoría de las nuevas funciones sólo se desarrollan en dicho controlador. Debido a que se escribe completamente en Java, este controlador no depende de la plataforma.
    • Controlador de cliente JDBC Thin: controlador JDBC Tipo 4 que utiliza Java para conectarse directamente a Oracle. Este controlador se utiliza internamente en la base de datos Oracle. Ofrece la misma funcionalidad que el controlador JDBC Thin del cliente (anterior), pero se ejecuta dentro de una base de datos Oracle y se utiliza para acceder a bases de datos remotas. Debido a que se escribe completamente en Java, este controlador no depende de la plataforma.
    • Controlador de cliente JDBC OCI: es un controlador JDBC de tipo 2 que utiliza métodos nativos Java para llamar a puntos de entrada en una biblioteca C subyacente. Esa biblioteca C, denominada OCI (Oracle Call Interface), interactúa con una base de datos Oracle. El controlador JDBC OCI requiere una instalación de cliente de Oracle de la misma versión que el controlador.

      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.

    • Controlador interno de servidor JDBC:: es otro controlador JDBC de tipo 2 que utiliza métodos nativos Java para llamar a puntos de entrada en una biblioteca C subyacente. Esa biblioteca C forma parte del proceso del servidor de Oracle y se comunica directamente con el motor SQL interno dentro de las llamadas y, por lo tanto, evita cualquier tráfico de red. Esto permite que el código Java que se ejecuta en el servidor acceda a la base de datos subyacente de la forma más rápida posible. Sólo se puede utilizar para acceder a la misma base de datos. El uso de métodos nativos hace que el controlador interno del lado del servidor JDBC sea específico de la plataforma. Este controlador es totalmente coherente con los controladores del cliente y admite las mismas funciones y extensiones.
  • ¿Qué controlador debo utilizar?

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

  • ¿Qué sucede con los archivos jar para el controlador Thin del servidor y el controlador interno 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.

  • ¿Pueden los proveedores externos distribuir los controladores JDBC de Oracle junto con su propio software?

    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.

  • ¿Qué permisos necesitan los controladores JDBC de Oracle?

    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.

Instalación

  • ¿Cómo instalo el controlador Thin?

    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.

  • ¿Cómo instalo el controlador OCI?

    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.

  • ¿Cómo instalo el controlador interno del lado del servidor o el Thin en el controlador del servidor?

    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?

DriverManager y DataSources

  • ¿Cuál es la diferencia entre DriverManager y DataSource?

    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);
     
     
  • ¿Qué pool de conexiones debo utilizar?

    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:

    • atributos de conexión para segmentar y reutilizar conexiones
    • un gestor de caché de conexión por máquina virtual para administrar una o más cachés de conexión
    • timeout de conexión abandonado para recuperar conexiones desprotegidas inactivas, etc.
    • Equilibrio de carga de conexión en tiempo de ejecución para asignar trabajo a las instancias con mejor desempeño

    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.

  • ¿Qué es el pool de conexiones JDBC OCI?

    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.

Conexiones

  • ¿Cuál es el formato de una URL?

    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.

  • ¿Cuál es la forma de la descripción de <database?

    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

  • ¿Cómo puedo utilizar el argumento Propiedades?

    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.

  • ¿No tengo que registrar la clase 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á.

  • ¿Qué nombre de usuario y contraseña debo utilizar al conectarse al controlador interno del servidor?

    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.

  • Aparece el error OutofMemory al definir un valor de recuperación previa predeterminada superior.

    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.

  • ¿Qué es una cadena de conexión de servicios?

    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.

  • ¿Cómo me conecto como SYSDBA o SYSOPER?

    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".

  • ¿Qué métodos de cifrado admiten los controladores JDBC de Oracle?

    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:

    • RC4_40
    • RC4_56
    • RC4_128
    • RC4_256
    • DES40C
    • DES56C
    • 3DES112
    • 3DES168
    • SSL
    • AES256
    • AES192
    • AES128
  • ¿Cómo activo el cifrado y el total de comprobación con el controlador JDBC Thin?

    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");
    
    
  • ¿En qué consiste la autenticación de proxy?

    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.

  • ¿Los controladores JDBC de Oracle son compatibles con SSL?

    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.

  • ¿Los controladores JDBC de Oracle admiten LDAP en la URL de conexión?

    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.

  • ¿Cómo puedo utilizar JDBC para conectarse a un servidor de base de datos detrás de un firewall?

    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.

Declaraciones, PreparedStatements, CallableStatements

  • ¿Qué es 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.

  • ¿Forza defineColumnType las conversiones en el servidor?

    No para el controlador Thin y sí para los controladores OCI y Server-Side Internal.

  • ¿Cómo desactivar EscapeProcessing en el nivel de controlador jdbc en lugar de llamar a stmt.setEscapeProcessing(false) en el código de aplicación?

    Utilice una propiedad 'CONNECTION_PROPERTY_PROCESS_ESCAPES' en OracleConnection.

  • ¿Proporcionan los controladores JDBC de Oracle una función de enlace por nombre?

    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.

  • En los métodos setXXX en PreparedStatement, ¿cómo determinan los controladores JDBC de Oracle el tipo de dato?

    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.

  • ¿Qué sucede si el tipo del parámetro de destino no es el mismo que el tipo asumido por el método setXXX?

    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.

  • ¿Por qué los conductores no realizan la conversión en el lado del cliente?

    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.

  • Para insertar en una columna de una tabla, ¿cuáles son los tipos de dato de bytes?

    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 introducir en una columna de una tabla, ¿cuáles son los tipos de dato de caracteres?

    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.

  • ¿Cuáles son los tamaños para setString, setCharacterStream y setAsciiStream?
    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  
  • ¿Cuál es el límite de tamaño de los datos binarios mediante setBytes y setBinaryStream?
    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;

    1. El controlador interno del servidor no puede convertir datos para parámetros BLOB de sentencias SQL de más de 2000 bytes. Esta limitación no existe para las sentencias PL/SQL. Se puede utilizar como solución alternativa en muchos casos ajustando SQL en PL/SQL. Por ejemplo, una cadena Java se inserta en los valores blob_tab (blob_col) (?)
    2. El método específico de Oracle setBytesForBlob se puede utilizar como una solución alternativa.
  • ¿Cuáles son los límites de tamaño de los métodos de propiedad setBytesForBlob, setStringForClob en oracle.jdbc.OraclePreparedStatement?
    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:

    1. El método específico de Oracle setStringForClob se puede utilizar como una solución alternativa.
    2. El método específico de Oracle setBytesForBlob se puede utilizar como una solución alternativa.
  • ¿La conmutación de tipos de enlace fuerza el análisis adicional del servidor de la sentencia?

    Sí.

  • ¿Qué sucede con 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.

  • ¿Cambiará la selección de procedimientos polimórficos PL/SQL cuando cambie el tipo de enlace?

    Sí. Tenga en cuenta que esto se puede aprovechar en el código PL/SQL.

  • ¿Qué sucede con el código existente?

    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.

  • En determinados casos, el controlador está creando lobs temporales. ¿Se realiza un seguimiento de estos y se liberan?

    Sí, se liberan después de la siguiente ejecución de la sentencia o cuando esta se cierra.

  • Estamos utilizando un juego de caracteres de ancho variable como UTF8. ¿El controlador corrige la longitud de bytes real de una secuencia de caracteres?

    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.

  • ¿Es una buena idea utilizar, por ejemplo, setString para una cadena realmente enorme?

    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.

  • Los tipos de columna 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.

  • Las API de LOB son mucho más flexibles, ¿verdad?

    ¡Por supuesto! Las API de LOB permiten el acceso aleatorio a cualquier parte del LOB. Considere utilizarlas cuando corresponda.

  • ¿Por qué no puedo crear una PreparedStatement que haga 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.

ResultSets

  • ¿Qué significa "Exhausted Resultset: prepare_for_new_get"?

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

  • ¿Por qué tengo que cerrar ResultSets?

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

Tipos de datos simples

  • ¿Qué sucede con 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:

    • Modifique las tablas para utilizar TIMESTAMP en lugar de DATE. Probablemente esto no sea posible casi nunca, pero es la mejor solución cuando lo es.
    • Modifique la aplicación para utilizar 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?).
    • Modifique la aplicación para utilizar 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.
    • Defina la propiedad de conexión 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.
      java -Doracle.jdbc.V8Compatible="true" MyApp

    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.

  • ¿Cuál es el valor más largo que puedo vincular?
    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.

  • ¿Por qué es el resultado de leer un 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.

Tipos de datos avanzados (objetos)

  • ¿Cómo debo crear instancias de ADT?

    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.

  • ¿Por qué no se admite el método de fábrica estándar 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.

BFILEs, BLOBs, CLOBs

  • ¿Qué hace DBMS_LOB.ERASE?

    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.

  • ¿Puedo utilizar oracle.sql.CLOB.putChars()?

    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.

  • OCI proporciona una función para manipular un CLOB CharSetId. ¿Cuál es el equivalente de JDBC?

    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.

  • ¿Es más lento escribir en BLOBS que insertar LONG RAWs?

    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.

  • ¿Por qué aparece un error ORA-03127 al obtener LobLength en el código de ejemplo de flujo?

    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.

  • Cuando obtengo un CLOB de la base de datos y, a continuación, lo actualizo, a veces mis cambios no aparecen en la base de datos. ¿Por qué?

    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.

Tipos de REF

  • ¿Cómo puedo transferir un oracle.sql.REF entre dos clientes JDBC diferentes (EJB, clientes JDBC, etc.)? Dado que la clase REF no es serializable

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

  • ¿Cómo puedo crear una nueva REF?

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

Tipos de OPAQUE

  • ¿Qué son los tipos de OPAQUE?

    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.

Fuentes de filas

  • Al definir el atributo de desplazamiento después de la ejecución, no afecta a la capacidad de desplazamiento de RowSet. ¿Por qué?

    Las propiedades de un bean se pueden clasificar como:

    • propiedades de creación de objetos
    • propiedades de tiempo de ejecución

    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.

  • ¿Puedo serializar el objeto RowSet en un archivo plano incluso si RowSet contiene flujos?

    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.

Controlador Thin

  • ¿Se puede utilizar el controlador JDBC Thin para desarrollar aplicaciones Java?

    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.

Controlador interno del servidor

  • ¿Cuándo debo utilizar el controlador interno del servidor?

    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.

Controlador thin del servidor

  • ¿Cuándo debo utilizar el controlador interno 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.

Errores

  • DriverManager.getConnection da el error: "Controlador no adecuado"

    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.

  • Mensaje de error: "UnsatisfiedLinkError with OCI driver"

    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.

  • Mensaje de error: "ORA-1019: imposible asignar memoria".

    Está utilizando el controlador OCI8 en una instalación de cliente Oracle7. Utilice el controlador OCI7.

  • Mensaje de error: "ORA-01000: máximo de cursores abiertos superado"

    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.

  • Mensaje de error: "ORA-01002: obtención fuera de secuencia"

    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.

  • Mensaje de error: "ORA-12705: valor de parámetro NLS no válido o desconocido especificado"

    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.

  • Error al intentar recuperar texto para el error ORA-12705.

    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.

  • Mensaje de error: el controlador JDBC Thin me indica errores de "carácter no válido" para literales Unicode

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

  • Las operaciones INSERT o UPDATE son lentas

    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.

  • Mensaje de error: "Connection reset by peer"

    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.

  • ¿Qué significa "violación de protocolo"?

    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.

Programas de demostración

  • ¿Existe algún programa de demostración de JDBC?

    Sí. Busque en $ORACLE_HOME/jdbc/demo/demo.tar en sistemas UNIX y en $ORACLE_HOME/jdbc/demo/demo.zip en sistemas Windows.

  • ¿Cómo puedo ejecutar las demostraciones?

    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.

  • ¿Qué debo hacer cuando se produce un error al ejecutar una demostración?

    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:

    • classpath
    • versiones correctas de jdk
    • Consulte Samples-Readme.txt, Makefile, y cada archivo .java para conocer los requisitos de las pruebas previas.

Utilidad de Rastreo JDBC de Oracle

  • ¿De qué se trata la utilidad de rastreo JDBC?

    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.

  • ¿Cómo puedo activar el rastreo de JDBC antiguo?

    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".

  • ¿Cómo puedo controlar el volumen de salida de rastreo?

    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:

    • none--sólo imprime el mensaje
    • predeterminado
    • thread: igual que el valor predeterminado más el nombre de thread
    • todos
  • ¿Dónde va la salida de rastreo?

    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.

  • ¿Cómo puedo desactivar DMS en un jar activado para DMS?

    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

Herramientas y procesos de desarrollo

  • ¿Puedo depurar programas JDBC con Symantec Visual Cafe?

    Visual Cafe ya no es compatible.

  • ¿Puedo depurar programas JDBC con Visual J++ de Microsoft?

    Visual J++ ya no es compatible.

Funciones compatibles

  • ¿Pueden los controladores JDBC acceder a procedimientos almacenados PL/SQL?

    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:

    • Sintaxis de SQL:2003 CallableStatement cs1 = conn.prepareCall ("{call proc (?,?)}"); CallableStatement cs2 = conn.prepareCall ("{? = call func (?,?)}");
    • Sintaxis de Oracle CallableStatement cs1 = conn.prepareCall ("proc de inicio (:1,:2); end;"); CallableStatement cs2 = conn.prepareCall ("inicio :1 := func (:2,:3); end;");
  • ¿Los controladores JDBC admiten la transmisión?

    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.

  • ¿Los controladores JDBC admiten juegos de caracteres multibyte?

    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.

  • ¿Funcionan los controladores JDBC con firewalls?

    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:

    • Firewalls de inspección con estado: firewalls desde el punto de control, SunSoft y sistemas CISCO.
    • Firewalls basados en proxy: Firewalls from Milkyway Networks, Trusted Information Systems, Raptor, Secure Computing Corporation e Internet global.
  • ¿Los controladores JDBC de Oracle admiten tablas/juegos de resultados/registros/booleanos PL/SQL?

    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;

  • ¿Se admite el failover?

    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.

  • ¿Cómo admiten los controladores JDBC los tipos de datos Oracle ROWID? ¿Qué tiene que ver esto con getCursorName y setCursorName?

    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.

  • ¿Cómo admiten los controladores JDBC los tipos de datos Oracle ROWID?

    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.

  • ¿Funciona ANO con controladores JDBC?

    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.

  • ¿Puedo serializar tipos de datos oracle.sql.*?

    Sí. Todas las clases oracle.sql.* que representan tipos de datos SQL se pueden serializar.

  • ¿Los controladores JDBC admiten objetos o recopilaciones?

    Sí, los controladores JDBC de Oracle admiten objetos y recopilaciones. Esto ha sido cierto desde la versión 8.1.5.

  • ¿Puedo utilizar WaitOption y AutoRollback?

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

  • ¿Puede un procedimiento almacenado Java en una instancia de base de datos abrir una conexión a otra instancia de base de datos?

    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.

Desempeño

  • ¿Cuál es más rápido, el controlador Thin o el controlador OCI?

    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.

  • ¿Qué es más rápido, las sentencias o PreparedStatements?

    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.

java.util.logging

  • ¿Cómo puedo utilizar java.util.logging para obtener la salida de rastreo de los controladores JDBC de Oracle?

    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.

  • ¿Cómo configuro 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.

  • ¿Qué sucede con el controlador interno del lado del servidor?

    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.