¿Por qué migrarse a Oracle Database 11g?

En la actualidad existen muchas empresas que aún poseen Bases de Datos 10g, 9i, incluso hasta 8i. Uno de los principales motivos por el que aún no han migrado a una versión más reciente es por problemas de aplicativo, presupuesto, hardware, entre otros. Sin embargo, es necesario tomar en cuenta que mientras más avance el tiempo más difícil será mantener versiones anteriores. Para hacer conciencia al respecto veamos lo siguientes datos interesantes:

• Oracle anunció que ya no brindará soporte Premier de Bases de Datos versión 9.2 en Julio del 2007. 
• Para clientes quienes están en versión 9.2, el Soporte Extendido finalizó en Julio del 2008.
• Para clientes quienes están en versión 10.1, el Soporte Premier finalizó en Enero del 2009. 
• Para clientes quienes están en versión 10.2, el Soporte Premier finalizó en Julio del 2010.

Estos datos nos dicen que conforme el tiempo avance, se hará más difícil encontrar soporte para problemas en versiones anteriores. Esto implica más costo, vulnerabilidad a permanecer siempre con un problema técnico debido a no encontrar soporte. Problemas para encontrar parches, mal rendimiento, dificultad para innovar los productos, dificultad al adoptar los cambios que el mercado exige.

Cuando se está considerando la migración de una base de datos, la característica más atractiva es la adopción de las nuevas capacidades que la nueva versión proporciona. Es éste el objetivo del presente artículo, darle a conocer algunas características importantes con las que cuenta Oracle Database 11g que puedan proporcionarle a su empresa mayor eficiencia.

Las capacidades que trataremos en este artículo son las siguientes:

• Nuevas capacidades que favorecen el cambio.
• Necesidades reducidas de almacenamiento.
• Fuerte aseguramiento de los datos.
• Mejor Rendimiento.
• Mayor Disponibilidad.
• Capacidades que mejoran la gestión de la base de datos.
• Fácil proceso de Migración.

Nuevas capacidades que favorecen el cambio: La empresa constantemente está presionada por nuevos cambios que exige el negocio, constantemente se están realizando parchado de aplicaciones, comprando nuevo hardware y/o software para mejorar el rendimiento pues cada vez la carga de trabajo aumenta, se tienen más clientes, más transacciones, más volúmenes de datos, etc. Esto lleva a que el área de IT constantemente esté testeando estas aplicaciones parchadas, hardware o software, antes de poder trasladar o adoptar dichos cambios en producción. Sin embargo, aunque se realice un testing intenso, pocos errores son detectados. La mayoría de errores son finalmente enfrentados de manera reactiva cuando se encuentra en producción, cuando se tiene la carga de trabajo real. Esto tiene como consecuencia que se realicen mantenimientos no planificados, un mal rendimiento o incluso hasta ventanas de tiempo sin servicio para poder corregir estos errores. Todos estos problemas se traducen a perdida en la inversión que se realizó para adquirir dichos cambios.

Oracle Real Application Testing combina capturas de carga de trabajo en producción para replicarla con un analizador de rendimiento SQL para ayudar a testear de manera más acercada a la realidad todos esos cambios que la empresa constantemente está haciendo para poder tener un enfoque competitivo ante el mercado. De esta manera, el tiempo de testing es reducido y se aumenta la calidad del resultado obtenido.

Necesidades reducidas de almacenamiento: En la actualidad, adquirir más capacidad de almacenamiento se ha hecho mucho más fácil y su precio ha ido disminuyendo considerablemente. Sin embargo, conforme el tiempo va avanzando la empresa cada vez necesita tener disponibles volúmenes de datos más grandes. Paralelamente a este crecimiento en datos debe de ir la escalabilidad y el rendimiento de las aplicaciones, pues mientras más volúmenes de datos se estén manejando se degrada el rendimiento.

Oracle Advanced Compression ofrece un conjunto de capacidades de compresión de datos que pueden ayudar a la empresa a enfrentar este crecimiento inevitable en los datos, de esta manera se reducirán los costos en la adquisición de almacenamiento pues lo datos ocuparán menos espacio. La compresión de datos también favorece el rendimiento, los datos serán gestionados mejor en memoria debido a que los datos están en un formato compreso, la red tendrá menos carga y se disminuirá las lecturas/escrituras. Oracle puede comprimir los datos hasta en un 75% (o más) de su tamaño original.

Fuerte aseguramiento de los datos: La empresa frecuentemente se enfrenta a la necesidad de tener los asegurados los datos que se transfieren en la red, en los respaldos que se realizan o dentro de la bases de datos como accesos no autorizados.

Oracle Advanced Security provee una solución fácil con la cual se protege toda comunicación entre la base de datos y quien la acceda, proveyendo métodos de encriptación nativas y encriptación basadas en SSL.

Oracle Database Vault controla el quién, cuándo y dónde los datos son accesados. Con esto la empresa está protegida de problemas de seguridad que frecuentemente afectan la información que se maneja, como lo son usuarios internos maliciosos o software malicioso.

Mejor rendimiento: Oracle Database 11g ha tenido avances radicales en el tema de rendimiento, gestionando mejor la memoria, los caches, la comunicación con la aplicación cliente y ha mejorado la ejecución de sentencias SQL hasta en un 25%. Los PL/SQL han sido mejorados de una manera más dramática y pueden mejorar hasta en un 50% y en java hasta 11 veces más rapido.  Oracle Real Application Cluster (RAC) también ha incorporado muchas capacidades que mejoran el rendimiento. La recaudación de estadísticas se ha hecho hasta 50% más rápida y más exacta en la información que recauda. Se ha incorporado nuevos métodos de particionamiento que buscan mejorar el acceso a los datos. La memoria ahora puede ser gestionada totalmente de manera automática tanto la memoria asignada al SGA como al PGA, aliviando el trabajo de administración que realizan los DBA’s.

Mayor Disponibilidad: La creación de ambientes de contingencia para hacer frente a los problemas que puedan producirse en la base de datos de producción se vuelve cada vez más comunes. El ambiente de continencia también proporciona el beneficio de poder aliviarle trabajo a la base de datos de producción sirviendo como ambiente para ejecutar reportería o redireccionar un subconjunto de las lecturas que la base de datos de producción realiza.

Oracle Activa Data Guard tiene la capacidad de poder crear sitios de contingencia que pueden estar sincronizando los datos mientras que puede estar abierta para lecturas y escrituras. De esta manera los datos estarán a la fecha. Esta mejora es un hibrido entre una Physical Standby y una Logical Standby que fueron incluidas en la versión 10g. En la versión 10g se presentaba el problema que una Logical Standby podía ser abierta mientras estaba sincronizando sus datos, sin embargo, no se soportaban todos los tipos de datos, en la versión 11g este problema está solucionado.

Capacidades que mejoran la gestión de la base de datos: Administrar una base de datos requiere un trabajo intenso y continuo de sus administradores, reduciendo así la eficiencia de los mismos. En Oracle Database 11g se ha tratado de realizar la mayoría de tareas automáticas, reduciendo la carga de los administradores y aumentando así su eficiencia y su calidad de trabajo.

Algunas de las características en 11g son las siguientes:

• Diagnostico de Monitoreo y diagnostico de rendimiento automático: Al realizar los diagnósticos de sistemas que están presenciando problemas de rendimiento se invierte muchas horas de trabajo intenso tratando de identificar la causa raíz. Existen muchas herramientas que ayudan al administrador proporcionándole gráficas y datos importantes, sin embargo, no dan soluciones puntuales. El Oracle Diagnostics Pack 11g  realiza un diagnostico de los eventos que actualmente están influyendo en el mal rendimiento de un sistema y proporciona recomendaciones listas para ser ejecutadas en dicho ambiente con el objetivo de reducir el tiempo que se invierte en el diagnostico.
• Afinación de sentencias SQL: Ayuda a identificar aquellas sentencias SQL que están teniendo un mal desempeño y proporciona recomendaciones para mejorarlas, como reestructuración de la sentencia, creación de vistas, índices, etc.
• Enterprise Manager Database Console: Esta herramientas está capacitada en esta nueva versión 11g con más funcionalidades las cuales tienen como objetivo reducir el trabajo del DBA. 

Fácil proceso de Migración: Oracle ha trabajado intensamente en simplificar la operación de migración, mejorando radicalmente la herramienta recomendada por excelencia: Database Upgrade Assistant (DBUA). El DBUA es una herramienta gráfica que va guiando al administrador en todo el proceso de migración, proporcionándole sugerencias, corrección de problemas, automatizando ejecución de scripts, entre otros, con el objetivo que el proceso de migración sea en su mayor parte automatizada. El DBUA tiene la capacidad de migrar bases de datos sencillas (single instance), Real Application Clusters (RAC) y Automatic Storage Management (ASM).

Sin embargo, no solo el DBUA existe para realizar migraciones. Existen otros métodos de migración, los cuales, su elección dependen de variables como: Sistema Operativo Origen, Sistema Operativo Destino, Tiempo aceptado para tener el sistema abajo, versión de Base de Datos origen, versión de base de datos destino, tamaño de la base de datos origen, entre otros.

A continuación, algunos de estos métodos adicionales:

• Exp/imp (export-import, herramientas antiguas).
• Expdp/impdp (export-import data pump)
• SQL Apply
• Manualmente
• Oracle Golden Gate
• Recovery Manager (RMAN)

Conclusión: Tener una versión actualizada de nuestra Base de Datos no solo proporciona ventajas en rendimiento, soporte, costos, manejabilidad, escalabilidad, disponibilidad, sino que también ayuda a alcanzar al enfoque competitivo que una empresa necesita para poder hacerle frente a las exigencias del mercado.

Topologías de Oracle Coherence Parte 4

Near Cache

En el artículo anterior (Parte 3: Topologia Distribuida) se trató la topología de replicación en Oracle Coherence, se vio que es una buena topología para soportar una alta tasa de escrituras pero que el rendimiento en las lecturas se ve degradado.

En este nuevo artículo se tratará la topología “Near Cache” la cual es un hibrido entre la topología de replicación y la topología distribuida teniendo como consecuencia lo mejor de ambas topologías, un buen rendimiento para lecturas y un buen rendimiento para escrituras.

La topología Near cache se divide en dos capas:

• Front Cache
• Back Cache

El Front Cache no es más que un subconjunto de elementos en cada uno de los nodos de Coherence, los cuales son accedidos localmente para realizar las solicitudes de lectura. De esta manera se alcanza una latencia nula (ventaja de topología de replicación).

El Back Cache se encarga de recibir todas las solicitudes de escritura tal como se realiza en la topología distribuida. Por medio de una clave hash se localiza el nodo que aloja el objeto y se realiza la escritura en ese nodo.

Entonces, toda solicitud de escritura es enviada directamente al Back Cache y toda solicitud de lectura es realizada por el Front Cache. La capa que tiene los objetos verdaderos es la Capa distribuida (Back Cache), por lo tanto, el Front Cache no es más que una imagen de lo que se tiene en el Back Cache con el único objetivo de hacer las lecturas locales y alcanzar una latencia nula. Acá existe un problema, el Front Cache puede tener objetos “caducados”. Para solucionar este problema la topología Near Cache proporciona las siguientes formas de desalojar objetos en el Front Cache:

• None
• Present
• All
• Auto

Método de desalojo de objetos NONE: No desaloja los objetos en el Front Cache. En algunas aplicaciones no es tan importante que los objetos muestren información a la fecha, puede tolerarse cierto retraso en los datos. La ventaja de este método es que no implica ninguna carga adicional en la red para poder mantener los datos a la fecha. No existe comunicación para sincronización entre  Front Cache – Back Cache. Sin embargo, no siempre se puede querer tener los datos atrasados por siempre, entonces quizás se deba usar alguna estrategia de expiración basado en tiempo.

Metodo de desalojo de objetos PRESENT: Este método realiza el desalojo de los objetos por medio de “listeners” los cuales son los encargados de monitorear los cambios realizados en el Back Cache y sincronizarlos hacia el Front Cache. Se deben crear tantos listener como objetos se tengan en el Front Cache. Es decir, para cada objeto en el Front Cache se debe crear un listener. Cuando un objeto es modificado en el Back Cache el listener es el encargado de desalojar el objeto caducado en el Front Cache y situar la nueva imagen de dicho objeto, esta sincronización es realizada de manera asíncrona, de tal manera que entre la modificación del objeto en el Back Cache hasta la modificación del objeto en el Front Cache existe un tiempo mínimo en el que el objeto aun sigue estando caducado. Por lo común este tiempo mínimo es aceptado, sin embargo, si se desea necesariamente tener los objetos en el Front Cache totalmente a la fecha se puede incurrir explícitamente en un bloqueo del objeto mientras el listener actualiza la imagen en el Front Cache. Por supuesto que la sincronización entre el Back Cache y el Front Cache generará más tráfico en la red por lo que esta es una de las desventajas de esta topología.

Método de desalojo de objetos ALL: Este método es muy parecido al método PRESENT, la diferencia radica en que en el método PRESENT se tiene que crear un listener por cada objeto situado en el Front Cache, mientras que en el método ALL se crea un solo listener. La ventaja de esto es que el número de ciclos de CPU se reducirán debido a que solo hay un listener procesando información, la desventaja es que el tráfico en la red se aumentará y quizás hasta se vean encolamientos debido a que solo existe un listener atendiendo las notificaciones de cambios en los objetos situados en el Back Cache. Por lo regular los ambientes que tienen más alta tasa de lecturas que de escrituras y están utilizando la topología Near Cache se deciden utilizar el método de desalojo PRESENT, pero si al contrario, se tiene una tasa de escrituras más alta a la de lecturas suelen utilizar el método ALL  para desalojar objetos caducados.

Método de desalojo de objetos AUTO: Este método realiza cambios automáticamente entre el método PRESENT y el método ALL basándose en estadísticas de las transacciones realizadas en cada una de las capas (Front Cache y Back Cache). La estrategia default de la topología Near Cache es AUTO, sin embargo, este método no necesariamente realiza un adecuado cambio entre los métodos PRESENT Y ALL  pues se basa en sus propias estadísticas, por lo que se aconseja establecer el método de manera explícita entre el PRESENT Y ALL, o usar NONE si es aceptable que las aplicaciones muestren datos que no estén necesariamente a la fecha.

En la siguiente imagen se realiza una operación de escritura del objeto D desde el nodo 1 de Coherence, este objeto es delegado directamente al Back Cache, el cual a su vez localiza que el objeto está alojado en el nodo 4 y su respectivo backup es alojado en el nodo 3. El Back Cache realiza pues la escritura del objeto en el nodo 4 y su respectivo backup en el nodo 3.

En la siguiente imagen se realiza una operación de lectura del objeto B, esta operación es realizada por el Front Cache, el cual  sabe que tiene que ir a traer la imagen más reciente del  objeto pues se encuentra caducada, dicha imagen es traída desde el nodo 2. También se realiza una lectura del objeto C la cual se realiza de manera local logrando una latencia nula.

CONCLUSION: Esta topología contiene las ventajas que proporciona la tecnología distribuida y la tecnología replicada, sin embargo, la desventaja es que se debe incurrir en un procesamiento adicional que es dado por el método de desalojo que se utilice. Es necesario también realizar un análisis previo para poder determinar el método de desalojo, pues si se tiene un método de desalojo no adecuado puede tener como consecuencia un mal rendimiento u objetos no desalojados adecuadamente.

Hasta aqui doy por finalizado el articulo de Topologias de Oracle Coherence, a continuación un link de cada uno de las partes conforman el articulo:

Parte 1: Introducción

Parte 2: Topología de Replicación

Parte 3: Topología Distribuida

Parte 4: Topologia Near Cache

Articulo Completo listo para descargarse en el siguiente link: https://www.dropbox.com/s/7dv1aom6u1lzqan/Topologias%20de%20Coherence.pdf

Datum-Oracle Technology Seminar

El día 28 de Noviembre del 2012 se llevó a cabo uno de los mejores eventos Oracle organizado en Guatemala, cuyo organizador fue la empresa Datum. Este Seminario se impartió en el horario de 8:00am a 12:30pm. Los consultores que formaron parte del portafolio de expositores fueron:

• Everest Medinilla (Gerente de soporte).
• Sergio Alonzo (Consultor en Inteligencia de Negocios).
• Rafael Cordon (Gerente de Consultoría)
• Deiby Gómez (Consultor Service Oriented Architecture).

 Algunos de los productos involucrados en la demostración fueron:

• Oracle Golden Gate
• Oracle SOA Suite
• Oracle Business Intelligence Suite
• Oracle Database 
• Oracle WebLogic
• Oracle JDeveloper

La agenda del evento fue la siguiente:

El evento se enfocó en el tema de “Integración de Datos”, siendo un tema muy crítico en la actualidad para las empresas que tienen problemas en innovación de sus productos por restricción de sus tecnologías y/o aplicaciones. A este evento asistieron más de 95 representantes de diferentes empresas Guatemaltecas.

Fue realizado en el Hotel Westin Camino Real de la zona 10 de la ciudad Capital de Guatemala. Los clientes pudieron disfrutar de un desayuno mientras escuchaban las conferencias.

A continuación el salón de conferencia que se utilizó para el evento:

Cada invitado fue registrado en la entrada del salón de conferencias.

A continuación una fotografía en la que me encuentro realizando una demostración de integración de procesos de negocio por medio de Business Process Execution language (BPEL) y Service Oriented Architecture (SOA).

Estoy muy orgulloso de pertenecer al Team Datum y con ello haber formado parte de éste tan prestigioso evento en el que pude compartir un poco de mis conocimientos y crear amistad con diferentes representantes informáticos y de Negocio de diferentes empresas Guatemaltecas.

Para los que asistieron y están viendo este artículo, espero que haya llenado las expectativas.

Base de Datos Standby En Cascada (10.2.0.4 sin broker)

Una Base de Datos Standby asegura alta disponibilidad, protección de datos y recuperación de desastres para datos empresariales. Oracle Data Guard provee un conjunto de servicios que crean, mantienen, manejan y monitorean una o más bases de datos standby. Data Guard mantiene esas bases de datos standby como copias  transaccionalmente consistentes de la base de datos de producción, por lo tanto si la base de datos de producción no está disponible ya sea por un corte planeado o no planeado, Data Guard puede realizar un cambio entre el rol primario y el rol standby,  minimizando así el tiempo de inactividad que implica el corte. Una configuración de Data Guard está formada por lo siguiente:

• Una base de datos de producción
• Desde una hasta nueve bases de datos Standby

La base de datos de producción puede ser sencilla o RAC.

Una base de datos Standby puede ser de dos tipos:

Physical Standby: Es una copia bloque a bloque idéntica de la base de datos primaria. Es sincronizada por medio de Redo Apply.

Logical Standby: Contiene la misma información lógica de la base de datos primaria, aunque la organización y las estructuras de los datos pueden ser diferentes. Es sincronizada por SQL Apply.

Cascaded Standby Databases: Para reducir la carga en su sistema primario, puede implementar destinos en cascada, es decir, una base de datos standby recibe datos redo desde otra base de datos standby en lugar de recibirlos directamente de la base de datos primaria.

Las configuraciones en cascada  soportadas son:

• PD-> PS-> PS 
• PD-> PS-> LS
• PD ->LS ->PS

Donde:     PD=Base de Datos Primaria

                 PS=Physical Standby

                 LS=Logical Standby

Nota: Una base de datos Standby no puede colocarse en cascada si su base de datos primaria es RAC.  Es posible crear una base de Physical Standby a partir de una Logical Standby de una base de datos primaria RAC, pero ésta ya no sería cascada de la base de datos primaria RAC. 

Las configuraciones no soportadas son:

• PD ->LS ->LS
• RAC ->PS ->PS
• RAC ->PS LS
• RAC ->LS ->PS
• RAC ->LS ->LS

Una physical standby puede soportar un máximo de nueve destinos remotos. Oracle recomienda que destinos en cascada únicamente sean usados para reportería o para aplicaciones que no requieran acceso a datos que  estén completamente a la fecha con el sitio primario.

Bases de datos Standby recibiendo datos redo desde una physical standby: El proceso para realizar un switchover o failover es exactamente el mismo en una configuración en cascada, porque todas las bases de datos physical standby retransmiten idénticos datos redo de la base de datos primaria. La única diferencia es el tiempo adicional que puede requerir la restauración de los datos redo.

Bases de datos Standby recibiendo datos redo desde una Logical Standby: Cualquier base de datos que recibe datos redo en cascada desde una Logical Standby no puede participar en un en un switchover con la base de datos primaria, únicamente bases de datos Logical Standby que reciben

indirectamente datos redo de la base de datos primaria.

Creación de una base de datos en cascada: Una base de datos standby en

cascada se crea siguiendo el proceso normal de creación de una base de datos standby ya sea logical o physical, según sea el caso, pero la diferencia es que están entrelazadas. El siguiente ejemplo asume que el sitio

primario tiene por nombre “boston”, el sitio Physical Standby (Layer 1) tiene por nombre “chicago” y el sitio Physical Standby (Layer 2) tiene por nombre “denver”. Se requiere crear un ambiente como el siguiente:

Primero se deberá crear una configuración Physical Standby con el proceso normal, luego se crea otra configuración Physical Standby pero tomando como base de datos primaria la primer Physical Standby. 

A continuación los pasos resumidos:

Creación de la primer Physical Standby (Layer 1):

• Backup de la base de datos primaria
• Transmitir el backup al sitio standby (Layer 1)
• Configurar Oracle Net (tnsnames, listener, etc)
• Realizar Duplicate en el sitio standby (Layer 1)

Las siguientes operaciones son sobre el sitio primario:

• Habilitar FORCE LOGGING 
• Crear Password File 
• Configurar un Standby redo log.
• Configurar parámetros de inicialización. Estos parámetros deben estar similar a los siguientes datos: 

DB_UNIQUE_NAME=boston

LOG_ARCHIVE_CONFIG='DG_CONFIG=(chicago,boston,denver)'

LOG_ARCHIVE_DEST_1='LOCATION=/arch1/boston/ VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=boston'

LOG_ARCHIVE_DEST_2='SERVICE=denver VALID_FOR=(STANDBY_LOGFILES,STANDBY_ROLE) DB_UNIQUE_NAME=denver'

LOG_ARCHIVE_DEST_3='SERVICE=chicago VALID_FOR=      (ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=chicago'

STANDBY_ARCHIVE_DEST=/arch1/boston/ 

REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE

• Habilitar Archive mode

En el sitio standby (Layer 1):

• Copiar el archivo de parámetros del sitio primario al sitio standby
• Establecer parámetros de iniciación. Los parámetros deben ser similares a los siguientes: 

DB_UNIQUE_NAME=chicago

LOG_ARCHIVE_CONFIG='DG_CONFIG=(chicago,boston,denver)' 

LOG_ARCHIVE_DEST_1='LOCATION=/arch1/chicago/ VALID_FOR=(ONLINE_LOGFILES,ALL_ROLES)DB_UNIQUE_NAME=chicago'

LOG_ARCHIVE_DEST_2='SERVICE=denver VALID_FOR=(STANDBY_LOGFILES,STANDBY_ROLE) DB_UNIQUE_NAME=denver'

LOG_ARCHIVE_DEST_3='SERVICE=boston VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=boston'

STANDBY_ARCHIVE_DEST=/arch1/chicago

En el sitio standby (Layer 2):

• Backup de la base de datos Layer 1
• Transmitir el backup al sitio standby (Layer 2)
• Configurar Oracle Net (tnsnames, listener, etc)
• Realizar Duplicate en el sitio standby (Layer 2)
• Copiar el archivo de parámetros del sitio primario al sitio standby
• Establecer parámetros de iniciación. Los parámetros deben ser similares a los siguientes:

DB_UNIQUE_NAME=denver

LOG_ARCHIVE_CONFIG='DG_CONFIG=(chicago,boston,denver)' 

LOG_ARCHIVE_DEST_1='LOCATION=/arch1/denver/ VALID_FOR=(ONLINE_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=denver'

LOG_ARCHIVE_DEST_2='LOCATION=/arch2/denver/ VALID_FOR=(STANDBY_LOGFILES,STANDBY_ROLE) DB_UNIQUE_NAME=denver'

STANDBY_ARCHIVE_DEST=/arch2/denver/

REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE

• Crear Password File.
• Iniciar la Physical Standby.
• Verificar que estén sincronizadas las bases de datos.

Conferencia Oracle SQL Tuning en Zacapa, Guatemala.

El día sábado 3 de noviembre del 2012, estuve invitado a participar como conferencista en el II  Encuentro Informático de la Universidad Mariano Gálvez con Sede en Rio Hondo, Zacapa. En este evento asistieron varios estudiantes de diferentes ciclos del pensum de Informática en la UMG, fue realizado en el Hotel El Atlántico, Km 126 carretera al Atlántico.

La agenda del evento fue la siguiente:

A mi conferencia le precedió un almuerzo al aire libre en el que tuve la oportunidad de compartir con varios estudiantes. Dicho almuerzo se realizó dentro de las instalaciones del Hotel El Atlántico frente a una piscina y rodeado de naturaleza.

La conferencia que impartí es Oracle SQL Tuning, en la que traté varios temas importantes para afinar sentencias SQL. Algunos puntos de mi conferencia fueron los siguientes:

• Arquitectura de la base de datos 11g.
• SGA, PGA y parámetros para configurarlos.
• Proceso de commit.
• Proceso de DML
• Indices basados en función.
• Ventajas y desventajas de utilizar índices.
• Buenas prácticas de diseño del diagrama ER.
• Optimizador basado en costos.
• Buenas prácticas para optimización de sentencias SQL.
• Errores comunes al crear sentencias SQL.

La conferencia duró aproximadamente 1 hora con 30 minutos.

En la siguiente imagen se estaba tratando el tema de las estructuras dentro del SGA y los procesos que gestionan estas estructuras. Procesos como el PMON, DBWn, LGWR, SMON, ARCn, etc.

En la siguiente imagen se estaban puntualizando las buenas prácticas para creación de los diagramas Entidad-Relacion: Tamaños de campos adecuados, eliminación de campos innecesarios, normalización completa de las tablas, creación de índices estratégicos, etc.

Al final de mi conferencia, me dieron un reconocimiento por mi participación en el Encuentro Informático, dicho reconocimiento es un diploma firmado por el Director y el Coordinador Académico  de la Universidad Mariano Gálvez, Zacapa.

Agradezco mucho a la Universidad Mariano Galvez con sede en Zacapa por hacerme la invitación de participar en tan agradable evento de Informática. También gradezco al Ing. Carlos Dávila y al Ing. José Chinchilla por permitir que mi participación en dicho evento se llevara a cabo.

¿Bug en JDeveloper con BPEL?

Desarrollando algunos servicios web compuestos me topé con un curioso detalle del JDeveloper al momento de generar el código del archivo xml (.bpel) de mi servicio web compuesto. El problema se produce cuando se realiza un servicio compuesto asíncrono que solamente consta de un elemento “receive”, un elemento “human task” (los componentes que genera automáticamente) y un elemento “callBack”. El generador de código del JDeveloper generá mal el nombre del elemento “human task” dentro del archivo .bpel, agregándole al final del nombre establecido un “_N”. donde N es un número. Por ejemplo si mi tarea se llama “HumanTask.taskservice”, el código generado será  “HumanTask.taskservice_1”. Por supuesto, la solución es tan sencilla, solamente hay que entrar al archivo xml y modificarlo manualmente, sin embargo, publico esté articulo para saber con la ayuda de la comunidad si a alguien más le ha pasado. ¿Es un bug de JDeveloper?

Datos del ambiente utilizado para reproducir el problema:

Windows 7 Home Premium 64 bits.

8 GB RAM, Core i5 2.53Ghz.

JDeveloper 11.1.1.5

BPEL 1.1 y BPEL 2.0 (En las dos versions se produce el mismo problema).

Para reproducir el error siga los siguientes pasos:

Abrir JDeveloper 11.1.1.5 y crear una Aplicación Nueva.

A esta aplicación agregamos un proyecto nuevo.

Elegimos un proyecto de tipo “SOA Project”.

Ingresamos un nombre al proyecto.

Elegimos la opción “Empty Composite” y luego clic en el botón “Finish”.

Se crearán todos los archivos del proyecto. (Ver cuadro azul).

Arrastramos un elemento “BPEL Process” (Cuadro rojo) hacia el área  “Components” (cuadro verde).

Ingresar un nombre al proceso, para fines de ejemplo dejé el nombre default. Elegir el “Template” “Asynchronous BPEL Process”. Luego dar clic en el botón OK.

Agregar un elemento “Human Task” (Cuadro rojo) en el área “Components” (Cuadro verde).

Ingresamos el nombre del elemento “Human Task”.  Dar clic en el botón OK.

Enlazamos el elemento “Human Task” a nuestro elemento “BPEL Process”. Luego de enlazar los elementos, dar doble clic en el elemento “Human Task”.

En la pestaña “General” únicamente ingresar el titulo de la tarea, los demás valores dejarlos con valor default.

En la pestaña “Data”, dar clic en el botón de “Agregar” (cruz verde) y seleccionar la opción “Add other parameter”.

Seleccionar la opción “Element” (Cuadro verde) y luego seleccionar el elemento “process” que está bajo la rama “BPELProcess1.xsd” (Cuadro azul). Este elemento es el valor default de ingreso hacia el proceso bpel. Luego dar clic en el botón OK de la ventana “Type Chooser”, y finalmente clic en el botón OK de la ventana “Add task Parameter”.

Dar doble clic en el area gris de “Edit Participant” (cuadro verde) y luego clic en el botón de “agregar”  y seleccionar la opción “Add User” (cuadro rojo).

Dar clic en el botón “…” (cuadro verde), luego elegir un “Application Server” (cuadro azul), seleccionar un usuario, dar clic en el botón “Select” y se verá que el usuario ha sido agregado correctamente al área “Selected user” (cuadro naranja), finalmente dar clic en el botón OK de la ventana “Identity Lookup” (cuadro negro) y luego clic en el botón OK de la ventana “Add Participant Type”.

Dar clic en el objeto “BPELProcess1.bpel” (cuadro celeste), luego arrastrar un elemento “Human Task” (cuadro rojo) y soltarlo en medio del elemento “receive” y el elemento “callBack” (Cuadro azul). Luego dar doble clic sobre el elemento Human Task que acabamos de crear.

Seleccionar en el campo “Task Definition” nuestro HumanTask creado, en este ejemplo se llama “HumanTask1”. Luego dar clic en el botón “…” (cuadro rojo).

Seleccionar el elemento “client:process” que está dentro de la variable “inputVariable”. Luego dar clic en el botón OK.

Asi se verá el servicio web compuesto final:

Finalmente le damos Desplegar a nuestro servicio web:

Hasta aquí todo lo hemos creado solamente con asistentes, ingresando los minimos valores que nos solicitaban, incluso los nombres los hemos dejado default (esto no cambia el resultado), sin embargo, cuando está en la fase de compilación falla, a continuación los errores:

Tal como indicaba al principio del artículo, el problema se produce porque al final del nombre de la tarea agrega un “_N”, donde N es un número. En este caso agregó “_1” al nombre “Humantask.TaskService”.  Si vemos el archivo .bpel de nuestro servicio compuesto veremos este código mal generado:

¿Cuál es la solución? Modificar manualmente el archivo “.bpel” y remover el adicional “_1” que aparece en los parámetros “partnerLink” del elemento “invoke” y del elemento “receive”.  (Ver en la imagen anterior las líneas de código subrayadas por una línea verde).

¿Es un bug?