viernes, 30 de noviembre de 2012

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.



jueves, 15 de noviembre de 2012

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.






miércoles, 14 de noviembre de 2012

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.






martes, 13 de noviembre de 2012

¿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? 



















Oracle ACE Director Award - Deiby Gómez

Thanks #OracleACE Program for this awesome certificate recognizing the work I have done in the community for the last year. Looking forwa...