Archive

Archive for the ‘Oracle’ Category

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: , , , ,

Oracle RAC, de momento, no es compatible con IPv6

18 de marzo de 2012 Deja un comentario

Pues eso.

Andaba yo preocupada últimamente debido a que empiezan a escasearnos las IPs en algunas de las subredes que conforman nuestra infraestructura y me puse a investigar sobre la posibilidad de abordar una migración a IPv6. En su día, cuando hicimos el diseño de subredes, contábamos con un puñadito de aplicaciones y el dimensionamiento de las subredes nos pareció exageradamente grande. Cinco años después, estamos a punto de morir de éxito, vista la cantidad de aplicaciones (nuevas y migradas de otros CPD de la organización) que nuestros clientes quieren traernos.

La falta de IPs libres en algunas de nuestras subredes con máscara 25 es algo que está a la vuelta de la esquina y me preguntaba si podía IPv6 ser la solución a nuestros problemas. Al fin y al cabo, nuestros compañeros de Redes ya andan con el tema y están preparados para poner alguna aplicación en modo piloto sobre IPv6.

En principio, la capa de aplicaciones, apoyada en apache+tomcat o jboss, no debería ofrecer problemas pero ¿qué hay de la capa de datos? En nuestro caso, la capa de datos se apoya mayoritariamente sobre clústeres de Oracle. Aunque intentaré hablar aquí con más detenemiento del tema, la configuración de las interfaces de red es un aspecto crítico de los clústeres de Oracle y algo me decía que la cosa no iba a ser tan sencilla.

Echándole un vistazo en la web de Oracle a Oracle Database 11g release 2 (new features), encontramos lo siguiente:

1.5.4 IPv6 Support

The following sections describe improvements in IPv6 networking support.

1.5.4.1 Complete IPv6 Support for JDBC Thin Clients

JDBC supports Internet Protocol Version 6 (IPv6) style addresses in the JDBC URL and machine names that resolve to IPv6 addresses. For example:

2001:0db8:0000:0000:0000:0000:0000:0001
1080:0:0:0:8:800:200C:417A

A JDBC URL would look like the following:

jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)
(HOST=[2001:0db8:0000:0000:0000:0000:0000:0001]) (PORT=5521))
(CONNECT_DATA=(SERVICE_NAME=boston.us.example.com)))

This feature provides Java interoperability with IPv6.

1.5.4.2 Complete IPv6 Support for JVM and Java Debuggers

IPv6 now provides support for the database resident Java virtual machine.

This allows Java applications running in the database to connect to and accept connections from both IPv4 and IPv6 hosts.

Parece indicar, pues, que la versión 2 de Oracle 11g incorpora por fin soporte para IPv6. En las notas de soporte sobre los nuevos drivers JDBC de Oracle 11g r2 nos advierten de que para activar el soporte para IPv6 será necesario parametrizar correctamente la máquina virtual java:

Internet Protocol Version 6 Support (IPv6)

This release of Oracle JDBC drivers supports Internet Protocol Version 6 (IPv6) addresses. For more information refer to “Internet Protocol Version 6 Support”.

Note:

All the new System classes that are required for IPv6 support are loaded when Java is enabled during database initialization. So, if your application does not have any IPv6 addressing, then you do not need to change your code to use IPv6 functionality. However, if your application has either IPv6 only or both IPv6 and IPv4 addressing, then you should set the java.net.preferIPv6Addresses system property in the command line. This enables the Oracle JVM to load appropriate libraries. These libraries are loaded once and cannot be reloaded without restarting the Java process.

Por lo que respecta al lado cliente la cosa está clara, pero ¿qué hay del lado servidor? ¿Es posible instalar una base de datos Oracle sobre un servidor que sólo tenga habilitado IPv6? La respuesta es: “depende”. Este white paper de septiembre de 2011 (PDF), Oracle Database and IPv6 Statement of Direction, matiza el asunto:

  • Desde la release 2 de Oracle 11g es posible la instalación de bases de datos sobre servidores sólo con IPv6.
  • No obstante, esto está soportado sólo para instalaciones stand alone, nada de clústeres con Oracle RAC ni, por supuesto, clusterware. Se pospone a versiones posteriores el soporte de IPv6 para entornos Oracle RAC.
  • Tampoco hay soporte para ASM sobre Windows. No menciona Linux, así que entiendo que sí es posible utilizar ASM en instalaciones stand alone sobre Linux con IPv6.

Parece que a las dificultades intrínsecas de migrar desde IPv4 a IPv6 tendremos que sumar que, a día de hoy, es incompatible con toda nuestra infraestructura de clústeres. Habrá que estudiar, pues, otras soluciones a nuestra escasez de IPs. Apache’s virtual hosts, you’re welcome!!

Categorías:Oracle Etiquetas: , , ,