DATUM & Oracle: SOA/BPM

El 10 de abril del 2013 se llevó a cabo uno de los eventos más importantes de oracle en Guatemala, organizado por la empresa DATUM S.A. y apoyado por Oracle Corporation. Dicho evento trató el tema de la agilidad empresarial y las soluciones de SOA  y BPM.

Se realizó en el Hotel InterContinental situado en la zona 10 capitalina de Guatemala y contó con conferencistas como Christian Medina quien habló sobre BPM, Deiby Gómez quien tuvo a su cargo la demostración de SOA y Rafael Cordón quien quien expuso los conceptos de SOA.

A continuación la invitación que Oracle envió:

Algunas fotografías del evento:

La conferencia de Christian Medina (Territory Manager Fussion Middleware) sobre BPM:

Pantalla completa:

http://www.youtube.com/watch?v=z348COBxFe4

extend/create datafile Single Instance vs Exadata

En mi preparación para someterme al examen de  1Z0-027 Oracle Exadata Database Machine X3 Administration, encontré un documento en el que resaltaba lo siguiente:

"With Exadata storage, the create/extend tablespace operation is executed more efficiently. Instead of formatting empty blocks in database server memory and writing them to storage, a single iDB command is sent to Exadata Storage Server instructing it to format the blocks. Database server memory usage is reduced and I/O associated with the creation and formatting of the database blocks is eliminated with Exadata storage."

Me llamó mucho la atención el hecho que una creación y/o extensión de un datafile implicase formatear bloques en blanco y luego escribirlos a disco. La primera impresión que me dio fue que se referían a bloques de oracle. ¿Recuerdan el mapeo entre estructuras físicas y lógicas en oracle?, si ya no lo recuerdan, les dejo la siguiente imagen.

Bueno, no me quedé con la curiosidad y extendí un datafile desde 250M hasta 8G y mientras el proceso avanzaba  vi si los bloques en el SGA cambiaban, no vi nada extraño.

Luego observé todas las estructuras del SGA y su espacio utilizado y libre pensando en que quizás esos bloques formateados en blanco eran creados en otra estructura diferente, tampoco vi nada extraño, todas las estructuras se mantuvieron con los mismo megas mientras el proceso de extensión del datafile se realizaba.

Hasta aquí ya estaba dudando de la documentación de Oracle, pensé que ese párrafo que había leído no era correcto, sin embargo, fiel a oracle y a su buen funcionamiento comprobado y asegurado :), descarté esa idea y se me ocurrió que quizás no era memoria de la base de datos la que era utilizada, sino la del propio servidor, entonces volví a realizar el proceso pero ahora monitoreando la memoria del servidor apoyándome de la herramienta top.

Los recursos del servidor estaban inicialmente como lo muestra la siguiente imagen:

Unos segundos antes que terminara el proceso de extensión del datafile, los recursos del servidor estaban así:

Una vez visto este comportamiento, ya mi curiosidad quedó satisfecha y pude concluir que en efecto, cada creación y/o extendido de un datafile implica consumir recursos de memoria del lado del servidor de la base de datos, y precisamente es esto, una de las características que Exadata ya tiene solucionado, por medio del iDB (intelligent database protocol) se le envía la instrucción de creación y/o extensión del datafile al Exadata Storege Server y él es el encargado de realizar esta operación, de esta manera el Database Server no tiene que ceder su memoria. Por supuesto, la memoria utilizada en el servidor con single instance es proporcional al tamaño en GB que estemos creando o extendiendo el datafile.

Por otro lado, si no somos el DBA de un Exadata y nos toca ganar el pan de cada día administrando un single instance :(, nos queda como lección crear y/o extender nuestros datafiles en un momento donde la base de datos no tenga tanta carga, pues de lo contrario el servidor puede paginear (swapping), degradando el performance. 

ORA-01078 ORA-29701

Sintomas:

Al iniciar la instancia de ASM se producen los siguientes errores:

grid>sqlplus / as sysasm

SQL>startup;

ORA-01078: failure in processing system parameters

ORA-29701: unable to connect to Cluster Synchronization Service

Reproducción del problema:

Ambiente:          Base de datos 11.2.0.3 con ASM sobre OEL 6 64 bits.

ps -ef |grep pmon

grid      5893     1  0 11:36 ?        00:00:01 asm_pmon_+ASM

oracle    5973     1  0 11:36 ?        00:00:02 ora_pmon_orcl

oracle>sqlplus / as sysdba

SQL>shutdown immediate;

grid>sqlplus / as sysasm

SQL>shutdown immediate;

-Se reinicia el servidor

root>reboot -f

-post-reinicio los servicios no levantaron automaticamente

grid>sqlplus / as sysasm

SQL>startup;

ORA-01078: failure in processing system parameters

ORA-29701: unable to connect to Cluster Synchronization Service

Explicación:

El CRS tiene la capacidad de conocer el estado en el que los servicios (bd y asm) se encontraban al momento del reinicio, de tal manera que cuando el servidor se reinicie y vuelva a iniciar el CRS, dejará todos los servicios como estaban. Entonces cuando se desea levantar manualmente post-reinicio el servicio de ASM (sqlplus / as sysasm, startup) es cuando se producen los siguientes errores:

ORA-01078: failure in processing system parameters

ORA-29701: unable to connect to Cluster Synchronization Service

La solucion para este caso puntual sería iniciar asm con "srvctl" y con usuario oracle: srvctl start asm;

Más no con sqlplus.

Esto no deberia pasar si modificamos la  propiedad AUTO_START=always dentro del CRS, esto hará que aunque los servicios fueron encontrados abajo al bajar el CRS, los vuelva a levantar una vez iniciado nuevamente el CRS. El valor "always" no es el default de oracle, el default es "restart".

AUTO_START puede tomar uno de los siguientes valores:

always=siempre levantará los servicios

never= nunca levantará los servicios

restore=dejará los servicios en el estado en el que se encontraban antes del reinicio.

Para ver qué valor de AUTO_START tiene cada servicio, ejecutar el siguiente comando:

crsctl status resource ora.orcl.db -p | grep AUTO_START

crsctl status resource ora.asm -p | grep AUTO_START

Soluciones:

1. Dejar que el CRS baje todos los servicios (no bajarlos manualmente):

1.1 logearse con el usuario root

1.2 export ORACLE_HOME=<home_grid>

1.3 export PATH=$ORACLE_HOME/bin:$PATH

1.4 crsctl stop crs

1.5 reiniciar el servidor

2. Cambiar el parametro AUTO_START al valor always, de esta manera aunque se baje manualmente servicio por servicio, cuando reinicie el CRS volverá a levantar todos los servicios.

(Estos pasos solo los tendrán que realizar una vez)

2.1 logearse con el usuario grid

2.2 crsctl modify resource ora.asm -attr AUTO_START=always

2.3 crsctl modify resource ora.orcl.db -attr AUTO_START=always

Siempre que se reinicie el servidor, voverá a levantar todos los servicios.

Reset password OER/OSR

Algunas veces necesitamos resetear el password de algún usuario dentro del OER u OSR cuyo repositorio de usuarios está amarrado a una base de datos Oracle, a continuación demostraré una forma fácil de poder realizar esto, para ello necesitamos de lo siguiente:

1. Conexión al esquema de OER/OSR
2. Conocer el password de cualquier usuario

Cada herramienta OER/OSR mapea sus objetos a tablas relacionales, de igual manera los usuarios  y contraseñas.

La tabla donde se guarda los usuarios y contraseñas para OER es ENTSECUSERS, tal como se muestra en la siguiente imagen:

El OSR de igual manera mapea sus usuarios y contraseñas a una tabla relacional, la cual es PASSWD, tal como se muestra en la siguiente imagen:

Bueno, el metodo para resetear la contraseña es facil, se resume en lo siguiente:

Copiar el password encriptado del usuario del cual conocemos su contraseña y copiarsela al usuario del cual queremos resetear la password.

Por ejemplo, para el Oracle Service Registry (OSR):

SQL> select loginname, password from uddi.passwd;

deiby                                              wkBkLd75lDWMltqCwDYaWA==

admin                                            uRzRpUeBeQvqorr3QfpniQ==

Y sabemos que la contraseña del usuario "deiby" es "oracle" y el usuario al que queremos resetearle la contraseña es "admin", entonces hacemos el siguiente update:

update uddi.passwd set password='wkBkLd75lDWMltqCwDYaWA==' where loginname='admin';

commit;

¡Listo! Ahora podremos logearnos al OSR con admin/oracle :)

Como recomendación, reinicie el Managed Server del OSR/OER.

Los mismo puede realizarse para el OER:

select username, password from oer.ENTSECUSERS;

deiby                                              wkBkLd75lDWMltqCwDYaWA==

admin                                            uRzRpUeBeQvqorr3QfpniQ==

update oer.ENTSECUSERS set password='wkBkLd75lDWMltqCwDYaWA==' where username='admin';

commit;

¿Funcionará el método con el DBA_USERS? pruebelo..... :)

Oracle Service Registry Cannot obtain new connection

En algunas ocasiones es posible que el Oracle Service Registry (OSR) no pueda obtener una conexión desde el pool de conexiones creadas por el Data Source, esto puede producirse después de volver a realizar el despliegue de la aplicación del OSR.

Si buscamos errores en el log del Managed Server donde está desplegada la aplicación es posible que no encontremos información relevante. El log que se debería revisar es entonces:

$DOMAIN_HOME/servers/<server_name>/tmp/_WL_user/registry/<random_directory>/public/serviceRegistry_errorEvents.log

En éste log vemos que las siguientes líneas aparecen:

<2013-04-11 15:46:02,557> - <ID1365713947710> <ERROR> <WSP4005> com.systinet.uddi.webui.WebUIRawService -  - EXCEPTION: org.systinet.uddi.account.AccountException: Initialization of accounts has failed. For help please contact the administrator of the registry.

<2013-04-11 15:46:03,518> - <ID1365713947711> <WARN> <WSP4005> database_core.com.systinet.uddi.config.management.DatabaseConfig - Ignoring exception in event handler, it may be caused by unavailablity of database. - EXCEPTION: java.lang.RuntimeException: com.systinet.uddi.database.DatabaseCoreException: (12021) Cannot obtain new connection.

<2013-04-11 15:46:03,561> - <ID1365713947712> <WARN> <WSP4005> database_core.com.systinet.uddi.config.management.DatabaseConfig - Ignoring exception in event handler, it may be caused by unavailablity of database. - EXCEPTION: java.lang.RuntimeException: com.systinet.uddi.database.DatabaseCoreException: (12021) Cannot obtain new connection.

<2013-04-11 15:46:03,563> - <ID1365713947713> <ERROR> <WSP4005> uddi_inquiry_v3.com.systinet.uddi.inquiry.v3.database.Get - DatabaseCoreException - EXCEPTION: com.systinet.uddi.database.DatabaseCoreException: (12021) Cannot obtain new connection.

<2013-04-11 15:46:03,565> - <ID1365713947714> <ERROR> <WSP4005> permission.com.systinet.uddi.permission.database.DBPermissionApiImpl - DatabaseCoreException - EXCEPTION: com.systinet.uddi.database.DatabaseCoreException: (12021) Cannot obtain new connection.

<2013-04-11 15:46:05,471> - <ID1365713947715> <ERROR> <WSP4005> uddi_inquiry_v3.com.systinet.uddi.inquiry.v3.database.Get - DatabaseCoreException - EXCEPTION: com.systinet.uddi.database.DatabaseCoreException: (12021) Cannot obtain new connection.

Como se logra ver en las lineas del log, claramente la conexión a la base de datos no se puede realizar. Entonces el problema puede ser causado por lo siguiente:

1. El Data Source está creado en el weblogic con credenciales no validas.
2. No hay comunicación entre la aplicación desplegada y el Data Sorce.

Sin embargo, al testear el Data Source desde el weblogic, se confirmó que el Data Source sí era válido y que las credenciales utilizadas eran correctas. Entonces solo queda una opción, el despliegue no se comunica con el Data Source.

Y aquí es donde viene la pregunta: ¿Cómo hace el despliegue para comunicarse con su Data Source?

Por intuición me recordé de aquella herramienta que el Oracle Service Registry trae con sus binarios llamada "setup.sh" o "setup.exe" según sea el SO sobre el cual este el OSR, me recordé que esta herramienta trae una opción de "reconfigurar la conexión a la base de datos", donde se puede elegir en crear un tablespace, utilizar un tablespace existe y crear el esquema adecuado o simplemente conectarse a un esquema ya existente.

Para ejecutar esta herramienta en modo consola agregar la opción " -c", ejemplo "./setup.sh -c"

Esta herramienta está ubicada en:

$REGISTRY_HOME/bin

Utilicé esta herramienta para reconfigurar la conexión a la base de datos. Seleccioné la opción de "conectarse a un esquema existente", ingresé los datos correctos de la base de datos: host, puerto, username, password, etc. La herramienta no retornó errores por lo que asumí que había realizado su tarea exitosamente.

Es necesario detenernos en este punto y revisar el log de la herramienta setup.sh, la cual se encuentra en:

$REGISTRY_HOME/log/setup.log

En este punto puede ser que muestre algún error relacionado con la librería "ojdbc6.jar" que debe estar agregada en el CLASSPATH del Managed Server donde está el OSR. Pero para mi problema, esta no fué la causa, pues la librería estaba correctamente agregada.

Bueno, prosigamos. Como indicaba, en el log del setup.sh no habian errores. Reinicié el Managed Server del OSR volví a ingresar a la aplicación y no, el problema no se habia solucionado, en el log seguía mostrando "Cannot obtain new connection". Por intuición pensé que esta herramienta "setup.sh" volvía a reconfigurar todo lo necesario para restablecer la conexión entre la aplicación y el Data Source, pero no, no fue así. Entonces volví a la misma pregunta  ¿Cómo hace el despliegue para comunicarse con su Data Source?

Investigando llegué a la solución, el despliegue utiliza un archivo XML para comunicarse con el Data Source, este archivo es llamado "database.xml" y está ubicado en:

$DOMAIN_HOME/servers/<server_name>/tmp/_WL_user/registry/<random_directory>/public/app/uddi/conf/database.xml

Este archivo es el que debe modificarse manualmente, indicando todos los datos correctos para lograr la conectividad con el Data Source: host, puerto, username, password, instance_name, data source name, etc.

Al modificar dicho archivo, reinicié el Managed Server del OSR, ingresé a la aplicación y pude por un momento imitar a Arquimides y exclamé ¡Eureka!

Los sabores y colores de Oracle Exadata

Oracle está promoviendo fuertemente la solución Oracle Exadata, un servidor diseñado para procesar grandes cantidades de datos (Exabytes), optimizado para OLTP o para DWH. Recordemos un poco los prefijos:

10³      kilo

10⁶      mega

10⁹      giga

10¹²    tera

10¹⁵    peta

10¹⁸   exa

Oracle sabe que constantemente los datos que se necesitan procesar se están incrementando, a continuación unos datos relevantes:

• 2 billones de personas usan internet, y estas están generando cada vez más datos.
• Un solo celular genera GB de información, multiplique esta información por el numero de celulares que existen ahora.
• En el año 2,000 un Estudio dedicado a investigaciones espaciales registró en una semana más información que la que se había recolectado en toda la historia.
• En 10 años una empresa de IT creció en datos hasta 140 Terabytes.

La arquitectura de este servidor es impresionante, toma en cuenta la optimización de varios aspectos como son IO, CPU, CACHE, Latencia, etc., desde el ensamblaje del hardware hasta los procesos que se ejecutan dentro de él. Consta principalmente de los elementos:

• Exadata Database Servers
• Exadata Storage Servers
• Infiniband
• Smart Flash Cache

Oracle Proporciona dos tipos de Oracle Exadata:

1. Oracle Exadata X2-2
2. Oracle Exadata X2-8

El Oracle X2-2 Posee los siguientes componentes de Hardware:

El Oracle X2-8 Posee los siguientes componentes de Hardware:

El Oracle Exadata X2-2 a su vez, existe en 3 formas:

1. Oracle Exadata X2-2 Full Rack
2. Oracle Exadata X2-2 Half Rack
3. Oracle Exadata X2-2 Quarter Rack

¿Es escalable Exadata? Claro que sí. Existen expansiones de Oracle Exadata. Por ejemplo, si se tiene un X2-2 Quarter Rack, se puede expandir a Full Rack. Si un Full Rack ya no es suficiente, se pueden agregar más Exadata Machines (cualquier clase). ¡¡¡Con dos switches adicionales se puede llegar a tener hasta 36 Exadata Machines en una sola configuración!!!

¿Estas Listo para Exadata?

Variable Vacía en BPEL

Hace unos días encontré con otros colegas un problema en el desarrollo de un servicio web con BPEL en JDeveloper 11.1.1.5 que quizás no es tan común, pero que siempre es bueno saber la solución, ya que al principio parecería muy raro el comportamiento del Motor de SOA en el Weblogic (10.3.5), más sin embargo, el verdadero problema radica en cómo estemos describiendo nuestros servicios, en este caso el problema se encontraba en el XSD.

Descripción:

Se realiza una invocación de un Servicio Web externo, mediante el elemento "invoke" del BPEL. El servicio web invocado es síncrono, por lo que recibe una entrada de datos y retorna datos de salida. Por lo tanto, en un elemento "invoke" se debe asociarle dos variables de BPEL, llamemosla "vinput" para la variable de entrada de datos y "voutput" para la variable de salida de datos.

Los datos retornados por el servicio mediante "voutput" se pasan a la variable de salida del servicio BPEL.

A continuación el diagrama del BPEL en JDeveloper, como verán es sencillo:

Síntomas:

Al debuggear la instancia de ese servicio SOA en el Enterprise Manager, se ve que la invocación del servicio externo es exitosa, se le envía datos de entrada y retorna los datos correctos de salida. Es decir la variable "vinput" es poblada por nosotros y la variable "voutput" es poblada por el "invoke", todo esto es exitoso.

Al querer utilizar los datos de "voutput" y pasarlos a la salida final del servicio SOA, el motor de SOA encuentra a la variable "vouput" VACIA y por lo tanto el nuestro servicio SOA no retorna datos.

A continuación una imagen donde se puede ver que se "voutput" es poblada con los datos de salida, pero en el "transform" NO hay datos.

El elemento "transform" es utilizado correctamente, se toman los campos de "vouput" y se mapean a los cambos de la salida del servicio SOA, se utiliza un elemento "for-each" pues el servicio retorna un array de datos.

A continuación la imagen del XSL.

Solución:

En el XSD del servicio Externo se utilizan las siguientes clausulas dentro del tag <XSD:SCHEMA>:

attributeFormDefault="qualified" elementFormDefault="qualified"

Al remover estas clausulas y volver a desplegar el servicio, la ejecución fue exitosa.

Antes:

<xsd:schema attributeFormDefault="qualified" elementFormDefault="qualified" targetNamespace="https://.......

Despues:

<xsd:schema targetNamespace="https://......