Archivo

Posts Tagged ‘thin’

Introducción a los drivers de acceso a bases de datos Oracle

18 de abril de 2012 Deja un comentario

Aunque pueda resultar sorprendente, en mi día a día como administradora de sistemas me he encontrado a menudo con que existe una notable confusión en cuanto al uso y configuración de los drivers de acceso a base de datos. Con frecuencia, los desarrolladores embeben la primera librería que encuentran (generalmente, la ojdbc14.jar) dentro de alguno de los directorios de su fichero war. Mientras están desarrollando en su PC funciona perfectamente, pero -¡oh, sorpresa!- cuando se despliega en el servidor de integración a menudo comienzan a aparecer diferentes excepciones de acceso a base de datos.

Como es un tema con el que nos hemos pegado bastante, he considerado interesante comenzar una serie de artículos sobre los diferentes tipos de drivers que proporciona Oracle para acceder a sus bases de datos y su configuración óptima, así como diversos aspectos de utilidad relacionados con los mismos.

¿Qué es un driver JDBC?

JDBC (Java DataBase Connectivity) consiste en una API estandarizada cuyo objetivo es independizar el código desarrollado en JAVA de las peculiaridades propias de cada base de datos relacional. Como cualquier otra API, se trata de que, si estamos desarrollando un programa que debe acceder a una base de datos, no tengamos que conocernos cada una de las interfaces de conexión de las diferentes bases de datos. Desde nuestro código, realizaremos llamadas estándar a JDBC y será el driver JDBC el que se encargue de “traducir” estas llamadas a un “lenguaje” que entienda la base de datos.

El estándar JDBC define cuatro tipos de drivers. El de tipo I precisa a su vez la instalación de un segundo driver (el ODBC) y el de tipo III emplea un tercer equipo como puente entre los equipos clientes y las bases de datos. No obstante, lo más habitual es utilizar drivers de tipo II o IV, que son los que vamos a ver a continuación, debido a su mayor portabilidad y facilidad de uso.

Al tratarse de una API estandarizada, existen numerosas implementaciones de JDBC realizadas por diferentes fabricantes. Como puede comprobarse en la antigua web de drivers JDBC de Sun (no sé lo que durará el enlace), al elegir un driver hay que tener en cuenta muchos aspectos tales como: la versión de la API JDBC que soporta, el tipo de driver (I, II, III o IV), las bases de datos con las que es capaz de trabajar o la implementación de JAVA para la que está certificado.

Como se ve, el tema en sí es complejo, por lo que lo habitual es utilizar el driver correspondiente a la base de datos con la que se va a trabajar y listo. En nuestro caso, tenemos bases de datos MySQL y Oracle, pero nos vamos a centrar en estos últimos debido a que existen más variables a la hora de elegir y configurar el driver.

Oracle proporciona cuatro modalidades de driver: THIN y OCI, que son de tipo cliente, y otros dos de tipo servidor (KPRB y Thin server-side, de los que no vamos a hablar aquí).

Driver de tipo IV: el thin de Oracle

Aunque no vamos a entrar mucho en detalles, un driver de tipo IV está enteramente escrito en JAVA, motivo por el cual es el tipo de driver más portable de los cuatro existentes. Es, probablemente, el más usado ya que se suele recomendar por defecto debido a su portabilidad: al estar completamente desarrollado en JAVA y no realizar llamadas a librerías nativas ni de base de datos ni de sistema operativo, no precisa ser instalado. Es, por tanto, ideal cuando no tenemos control sobre lo que se va a instalar en el servidor, ya que podemos incluir todo lo necesario para que funcione nuestra aplicación dentro del war que vayamos a desplegar.

En el caso concreto de Oracle, su driver de tipo IV se denomina THIN. Como se ha comentado en el párrafo anterior, no requiere instalación de software Oracle, ya que para su utilización basta con añadir el .jar del driver dentro del paquete de nuestra aplicación o bien en el directorio de librerias compartidas JAVA del servidor de aplicaciones (por ejemplo, en el common/lib de tomcat).

¿Así de fácil? Bueno, en realidad no, porque el hecho de que sea portable y no requiera instalación no implica, como veremos, que no tenga dependencias fuertes con la versión de JAVA instalada en el servidor ni con la versión de base de datos de Oracle contra la que vamos a trabajar.

Driver de tipo II: el oci de Oracle

Un driver de tipo II presenta una parte escrita en JAVA y otra parte que emplea las librerías nativas de la base de datos. Es, por tanto, un driver dependiente de cada sistema gestor de base de datos que requiere instalación de las APIs de base de datos en el cliente. Como parte del driver está realizado con librerías nativas, el rendimiento es mayor a costa de no ser portable.

La falta de portabilidad se debe a que en su funcionamiento realiza llamadas a librerías de enlace dinámico escritas en C (.so en Unix, .dll en Windows). Por tanto, no basta con incorporar el fichero .jar del driver al .war de nuestra aplicación como pasaba en el caso del THIN. Esto, simplemente, no funciona ya que las clases JAVA del .jar que contiene el driver harán las llamadas correspondientes a librerías dinámicas y, al no estar instaladas, obtendremos una excepción semejante a la siguiente:

java.lang.UnsatisfiedLinkError: oracle.jdbc.driver.T2CConnection.getLibraryVersionNumber()I
at oracle.jdbc.driver.T2CConnection.getLibraryVersionNumber(Native Method)
at oracle.jdbc.driver.T2CConnection$1.run(T2CConnection.java:3536)
at java.security.AccessController.doPrivileged(Native Method)
at oracle.jdbc.driver.T2CConnection.loadNativeLibrary(T2CConnection.java:3531)
at oracle.jdbc.driver.T2CConnection.logon(T2CConnection.java:266)
at oracle.jdbc.driver.PhysicalConnection.<init>(PhysicalConnection.java:536)
at oracle.jdbc.driver.T2CConnection.<init>(T2CConnection.java:162)
at oracle.jdbc.driver.T2CDriverExtension.getConnection(T2CDriverExtension.java:53)
at oracle.jdbc.driver.OracleDriver.connect(OracleDriver.java:521)
at java.sql.DriverManager.getConnection(Unknown Source)
at java.sql.DriverManager.getConnection(Unknown Source)
at com.rhs.db.conn.ConnectionOra.useOCIDriver(ConnectionOra.java:82)

El driver de tipo II de Oracle se denomina OCI y puede descargarse de la web de Oracle en un paquete conjunto con el driver THIN, en lo que que suele denominar como instant client basic. Ya hablaremos más adelante en otros post de esta serie acerca de cómo instalar y configurar ambos, pero ya adelantamos que la configuración del OCI no es trivial y, si nuestro servidor de aplicaciones no tiene correctamente configuradas las rutas para acceder a las librerías dinámicas, obtendremos el error anterior al usar el OCI a pesar de tenerlo instalado, cosa que no ocurrirá si nos decantamos por el THIN.

Entonces, si no es portable y resulta más difícil de usar, ¿por qué usar el driver OCI? Bueno, no todo iban a ser inconvenientes o, de lo contrario, se habría abandonado hace tiempo el desarrollo del driver OCI. Ya hemos comentado que proporciona un mejor rendimiento que el THIN, pero es que además este no soporta características avanzadas de Oracle como los servicios TAF y, por tanto, resulta inadecuado para configurar accesos a entornos en RAC. Si nuestra base de datos es un clúster de Oracle RAC, sin duda deberíamos utilizar el driver OCI, no solo por rendimiento, sino porque existen determinadas funcionalidades avanzadas relacionadas con el failover y el balanceo de los clústeres que, o no están soportadas, o presentan un comportamiento menor con el driver THIN que con el OCI.

En próximos posts hablaremos sobre otros aspectos de los drivers Oracle que suelen llevar a confusión como la matriz de compatibilidad, los distintos paquetes de clientes que proporciona Oracle, solución de algunos problemas habituales, etc.

Categorías:Oracle Etiquetas: , , , ,