Newsletter Abril 2013 Contenido Conexión a Base de Datos 10.2 Por Medio de SCAN Página: 1 Conexión a Base de Datos 10.2 Por Medio de SCAN 4 Aplicación Web Para Móvil con APEX 4.2 Por Ing. Augusto López alopez@datum.com.gt Conexiones a RAC 10.1, 10.2 y 11.1 Hasta la versión de Oracle Clusterware 11.1 la cadena de conexión de los clientes es de la forma: erp = 9 Oracle JRockit (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = racnode1)(port = 1521)) (ADDRESS = (PROTOCOL = TCP)(HOST = racnode2)(port = 1521)) (LOAD_BALANCE = yes) Editores Generales 5a. Ave. 5-55 Zona14,Edificio Euro Plaza Torre II, Nivel 12 (FAILOVER = yes) (CONNECT_DATA = (SERVICE_NAME = erp)) Teléfono: Deiby (502)2364-5300Fax: Mauricio Gómez (502)2364-5311 ) Email.info@datum.com.gt Alejandro Lau Pagina 1/10 Debbie Morán Autores Contribuyentes Augusto López Jonathan Morales Daniel Caciá Cuando se modifica el número de nodos del cluster, por adición o eliminación de servidores, se hace necesario modificar la cadena de conexión para ajustarla a la nueva configuración. Por ejemplo, si se adiciona un tercer nodo al cluster, la cadena de conexión tendría que modificarse para que quede de la siguiente forma: erp = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = racnode1)(port = 1521)) (ADDRESS = (PROTOCOL = TCP)(HOST = racnode2)(port = 1521)) (ADDRESS = (PROTOCOL = TCP)(HOST = racnode3)(port = 1521)) (LOAD_BALANCE = yes) (FAILOVER = yes) (CONNECT_DATA = (SERVICE_NAME = erp)) ) Esto no tendría inconveniente si hubiera que modificar pocos archivos (en tres servidores de aplicación por ejemplo), pero cuando se ven involucrados cientos de clientes (en un entorno cliente/servidor, data sources en servidores de aplicación, etc.), el problema se incrementa. Página 1
1. 2. Conexiones a RAC 11.2 A partir de Grid Infrastructure (GI) 11.2, la forma de referenciar al cluster cambia de tal manera que ahora se hace por nombre. Se hace uso de un único nombre denominado SCAN: Single Client Access Name. Aunque puede asignarse cualquier nombre al SCAN, la convención que suele usarse es de la forma <clustername>-scan, donde <clustername> es el nombre del cluster. Por lo anterior, ahora la cadena de conexión queda de la siguiente forma: erp = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = cluster-scan)(port = 1521)) (CONNECT_DATA = (SERVICE_NAME = erp)) ) Cuando la configuración del cluster cambie, por adición o eliminación de servidores, NO será necesario modificar la cadena de conexión de los clientes. Esta forma de conexión queda lista para usarse si la base de datos en cluster es versión 11.2, sin embargo, si la base de datos es, por ejemplo, versión 10.2, es necesaria una configuración previa para hacer uso del SCAN. Por qué tener RAC 10.2 con GI 11.2? Existen, entre otras, dos razones para hacer esto. La primera es que GI 11.2 trae funcionalidades muy útiles, como el Cluster Time Synchronization Services (CTSS) para mantener sincronizada la hora de los servidores y el HAIP para tener el Interconnect en alta disponibilidad en un esquema activo/activo. Además, es más fácil actualizar la versión del Clusterware que la versión de base de datos en términos de certificación de las aplicaciones. La segunda es, precisamente, que las aplicaciones pueden tomar algún tiempo en certificar la nueva versión de base de datos. Se puede migrar a nuevos servidores con GI 11.2 y mantener la base de datos en 10.2 mientras se certifica la aplicación. Si las ventanas de mantenimiento son cortas, el cambio deberá hacerse obligatoriamente en dos fases: primero actualizar el Clusterware y luego la base de datos por lo que, durante algún tiempo, deberían existir ambas versiones. Configurar RAC 10.2 para usar SCAN Para que los clientes puedan conectarse a una cluster database 10.2 a través de SCAN, debe hacerse la siguiente configuración: 1. Fijar los servidores del cluster con usuario root. Página 2
# cd $GRID_HOME/bin #./olsnodes -n -t #./crsctl pin css -n racnode1 #./crsctl pin css -n racnode2 #./olsnodes -n -t 2. Crear listener.ora en 10.2 como link simbólico hacia GI con usuario oracle. $ cd $DB10G_HOME/network/admin $ ln -s $GRID_HOME/network/admin/endpoints_listener.ora listener.ora 3. En archivo de configuración de ambiente del usuario oracle definir la variable TNS_ADMIN. TNS_ADMIN=$DB10G_HOME/network/admin 4. Definir los siguientes parámetros a nivel de instancia de base de datos. *.REMOTE_LISTENER='cluster-scan:1521' ORCL1.CLUSTER_INTERCONNECTS="192.168.10.1:192.168.20.1" ORCL2.CLUSTER_INTERCONNECTS="192.168.10.2:192.168.20.2" donde: cluster-scan es el nombre del SCAN, 192.168.10.1 y 192.168.10.2 es la red privada número 1, 192.168.20.1 y 192.168.20.2 es la red privada número 2, el puerto del scan listener es 1521 y ORCL1 y ORCL2 son los nombres de las instancias de base de datos. Luego de realizar esta configuración, los clientes que deseen conectarse a la base de datos 10.2 pueden hacerlo a través de la siguiente cadena de conexión: erp = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = cluster-scan)(port = 1521)) (CONNECT_DATA = (SERVICE_NAME = erp)) ) Algo importante de hacer notar es que la anterior forma de conexión, referenciando a todos los servidores del cluster, sigue estando disponible. Página 3
Por Ing. Jonathan Morales jmorales@datum.com.gt Aplicación Web Para Móvil con APEX 4.2 Oracle Application Express (APEX) es una herramienta que nos permite el desarrollo de aplicaciones web de una forma rápida y declarativa. El desarrollo está basado sobre los distintos objetos de la base de datos Oracle, en la cual pueden emplearse los conocimientos de SQL y PL/SQL para lograr mayor flexibilidad. Uno de los objetivos de esta herramienta es generar aplicaciones empresariales en un tiempo corto, potenciando la productividad. Ya en su versión 4.2, APEX ofrece facilidades para desarrollar aplicaciones orientadas a dispositivos móviles, como smartphones y tablets. Además, se sigue manteniendo la posibilidad de visualizarse en navegadores web de escritorio. Para ello, dispone de una serie de componentes para mejorar la experiencia del usuario desde su dispositivo móvil, debido a que las páginas web utilizan jquery Mobile para desplegar el contenido. Incluye un nuevo tema adecuado para la disposición de los elementos de la aplicación en el entorno móvil, siendo compatible con acciones de utilización (como el toque, deslizamiento o pellizco ). Asimismo, está basado en los principios de diseño basado en respuesta, la cual se ajusta de forma automática a las dimensiones de la pantalla. También en esta versión se incluyen gráficos de HTML5 o Flash, ya que si no se detecta Flash automáticamente se despliegan con HTML5. Características adicionales introducidas en la versión 4.2: Enfoque en aplicaciones móviles por medio de jquery Mobile. Tema para visualización en dispositivos móviles. Gráficos en HTML5. Nuevos componentes de diseño, como Slider, HTML5 Date Picker, Toggle Switch, un nuevo calendario más amigable, utilización de vistas en forma de lista. Desarrollo de aplicación móvil en APEX 4.2: A continuación se describen los pasos para desarrollar una aplicación básica optimizada para dispositivos móviles. La aplicación se hará sobre las tablas de empleados (EMP) y departamentos (DEPT), para mostrar el proceso de desarrollo. Página 4
Lo primero es seleccionar el método para crear la aplicación, en este caso es de base de datos. A continuación se eligen los datos de la aplicación, tales como el ID, nombre, el esquema base de datos. En este paso debe elegirse la interfaz de usuario: jquery Mobile Smartphone. Página 5
Crear las páginas: se agregan las páginas para desplegar los datos de las tablas DEPT y EMP. Notar que se utilizará el tipo List View and Form, el cual se adapta para visualizarse cómodamente en el dispositivo móvil. Shared Components: se selecciona No. Attributes: puede seleccionarse el idioma deseado y formato de fechas. User Interface Theme: se utilizará el tema jquery Mobile Smartphone. Página 6
Finalmente se muestran las características de la aplicación y se confirma para que sea creada. La estructura de páginas de la aplicación recién creada: Página 7
Visualizando la aplicación creada en un dispositivo móvil: Página 8
Oracle JRockit Por Ing. Daniel Caciá dcacia@datum.com.gt Para poder instalar Weblogic es necesario instalar una máquina virtual de java (JVM) y para cumplir con ese requisito, Oracle ofrece dos opciones, instalar Oracle JDK o instalar Oracle JRockit. Anteriormente, a diferencia de Oracle JDK, JRockit debía ser licenciado, implicando un costo adicional. En mayo de 2011 Oracle liberó JRockit y por lo tanto la máquina virtual pasó a ser pública. Por lo tanto, la elección de máquina virtual se toma en función de las características de cada una. Como sabemos, la JVM es la responsable de convertir el código binario de java en código de máquina. Ambas máquinas virtuales hacen lo mismo pero utilizan diferentes mecanismos y estas diferencias son las que harían que la decisión se inclinara por una u otra. Cabe mencionar que Oracle JRockit fue originalmente desarrollada por Appeal Virtual Machines y luego adquirida por Bea Systems en el 2002, la cual pasó a formar parte del Oracle Fusion Middleware en el 2008 y como se mencionó, en mayo del 2011, Oracle JRockit fue liberada y hecha pública. Muchas de las clases que utiliza el JRE de Oracle JRockit son una réplica exacta de aquellas que son distribuidas con el JDK y otras han sido sobrescritas de una forma casi idéntica para mantener la compatibilidad mientras se mejora el rendimiento. En las siguientes líneas describiremos las diferencias entre una y otra. Oracle JDK utiliza interprete Con este mecanismo, el código binario es leído y luego traducido en lenguaje de máquina, pero los resultados no son guardados en memoria. De esta cuenta, si el mismo código se ejecuta una y otra vez, la JVM tiene que traducir el código constantemente, esto significa que el código de máquina no es reutilizable. Sin embargo, las últimas versiones incluyen HotSpot que funciona de una forma muy parecida a JIT. Oracle JRockit utiliza el compilador JIT (Just In Time) Usar JIT significa que, una vez que se ejecute el método, el código se almacena en memoria y si hay que ejecutarlo de nuevo, no hay necesidad de traducirlo otra vez. Debido a que JDK utiliza el mecanismo de interpretación, el tiempo de inicio del servidor será mucho más rápido porque no almacena nada en memoria. Una vez que la traducción de un método se ha realizado, procede a traducir el siguiente. Mientras tanto, JRockit almacena información en memoria, por lo que el inicio lleva un poco más de tiempo y esto mismo resulta en que JRockit utiliza más memoria que JDK. JRockit optimiza el código identificando los HOT SPOTS que son los métodos que se utilizan regularmente y estos métodos son encolados para mejorar el rendimiento. Página 9
Espacio de memoria en JDK JDK maneja los siguientes espacios de memoria: eden space, survivor space, tenured generation y permanent generation. Los objetos se mueven entre uno y otro espacio de acuerdo con su edad y si sobreviven al garbage collector. "Eden space" es donde nacen la mayoría de los objetos. "Survivor space" contiene los objetos que sobrevivieron a la acción del garbage collector sobre el "eden space". "Tenured generation" contiene todos los objetos que han residido por mucho tiempo en el "survivor space". Por último, "permanent generation" contiene el código estático de la máquina virtual de java necesario para que las aplicaciones puedan correr. JRockit solo utiliza dos espacios, "young generation" y "old generation" y el mecanismo de garbage collection. No hay nada conocido como "permanent generation" en JRockit. Una de las grandes ventajas JRockit es que el algoritmo de "recolección de basura" es más eficiente y está muy integrado con el sistema operativo, por lo que la recolección es más rápida y no afecta el rendimiento de las aplicaciones.. Crash del JVM Cuando JRockit tiene un crash, se genera un dump con la causa por la que se detuvo, dando la opción al usuario de resolver el problema. En cambio, cuando JDK tiene un crash, se produce un gran archivo conteniendo toda la información en memoria al momento del incidente. Normalmente, los dump del JDK deben reportarse al equipo de Oracle Sun. Herramientas de rendimiento y puesta a punto JDK, que viene embebida con el Weblogic Server, contiene herramientas como JConsole que se pueden utilizar para monitorear la memoria utilizada por la máquina virtual. Esta herramienta es necesaria para identificar el uso de memoria por aplicación, CPU utilizado y "memory leaks". JRockit tiene un conjunto de herramientas más avanzadas como JRockit Mission Control (JRMC), que provee de técnicas avanzadas de rastreo. Con esta herramienta se puede registrar el detalle de los argumentos de la JVM, detalles de la recolección del garbage collector, métodos que utilizan el máximo de memoria, etc. El detector de "memory leak" en el JRMC es parte importante de esta herramienta pero sobre todo muy útil. Por lo anterior, es fácil para el usuario y administradores mantener un registro e identificar los problemas de las aplicaciones y del JVM. Página 10
Conclusiones Oracle ha presentado su estrategia con la Máquina Virtual de Java y ha decidido integrar ambas máquinas virtuales en una sola. Tanto es su compromiso hacia esta estrategia que JRockit no obtendrá su "versión 7". Esta integración puede llevar varios años por lo que mientras esto es una realidad, podemos apuntar los siguiente: Oracle JVM y Oracle JRockit son en esencia lo mismo, sin embargo JRockit tiene ciertas herramientas que permiten mejorar el rendimiento de una forma más sencilla y ordenada. Existen varios estudios donde se compararon las dos máquinas virtuales y no se han concluido diferencias significativas de rendimiento entre una y otra. Sin embargo, si es notorio que la "recolección de basura" es mucho más eficiente utilizando JRockit y que en determinados momentos, este proceso puede "congelar" por algunos instantes Oracle JDK. Debemos tomar en cuenta que para Oracle Forms, Reports, Portal y Discoverer, JRockit no ofrece soporte. De ocupar estas herramientas deberíamos utilizar JDK. Sin embargo, si nuestro desarrollo es enteramente Java, JRockit debería ser nuestra opción. TIP TÉCNICO DEL MES Redireccionamiento de conexiones en Oracle RAC Database: Cuando nos conectamos a una base de datos Oracle RAC con más de un nodo, es el cliente de Oracle Net quien decide hacia qué nodo o servidor establece la conexión inicial. Si se usa LOAD_BALANCE, se selecciona el nodo aleatoriamente. En caso contrario, se selecciona el primer nodo en la lista del string de conexión. Sin embargo, el listener del nodo seleccionado puede indicar al cliente que se reconecte hacia otro nodo (redireccionamiento de conexión), por balanceo de carga del lado de los servidores. Por esta razón es importante que los cliente conozcan a los nodos por sus nombres públicos y virtuales. Es decir, no se vale utilizar IPs quemadas en el string de conexión, ya que pueden ocurrir errores al momento de conexión. Por Ing. Alejandro Lau alau@datum.com.gt Página 11