Upgrade desde ODI 11g a ODI 12c

Hace unos meses Oracle presentó la nueva versión de Oracle Data Integrator. En este post vamos a detallar los pasos necesarios para migrar los objetos de ODI desde la versión 11g a la versión 12c.

En la instalación de ODI 11g que queremos migrar tenemos creadas tres interfaces que cargan datos de ficheros de texto y tablas Oracle a tablas Oracle. Las interfaces son sencillas, pero tienen joins, filtros y expresiones que necesitamos que se traspasen correctamente si no queremos perder la funcionalidad implementada.

ODI 11g Interface

Para poder migrar una instalación de ODI 11g a 12c es necesario que se cumplan unos requisitos:

  1. La versión de la base de datos donde se instalaron los Master y el Work Repository para ODI 11G tiene que estar soportada y certificada para Oracle Fusion Middleware 12c (comprobarlo en http://www.oracle.com/technetwork/middleware/ias/downloads/fusion-certification-100350.html).
  2. La base de datos de los esquemas del Master y del Work Repository 11g tiene que ser UTF-8.

Si así no fuera, hay que migrar previamente a una base de datos que tenga estas características.

Antes de empezar, es aconsejable realizar un backup tanto del Master como del Work Repository 11g porque después de que se haya realizado el upgrade ya no será posible utilizar los esquemas en una instalación de ODI 11g. Para clonar los esquemas involucrados, se han seguido los siguientes pasos:

  1. Export de los esquemas del Master (ODIM) y del Work (ODIW) Repository

    exp userid=ODIM/ODIM file=ODIM11.dmp

    exp userid=ODIW/ODIW file=ODIW11.dmp

  2. Creación de nuevos usuarios

    create user ODIM11 identified by …;
    create user ODIW11 identified by …;
    grant connect, resource to ODIM11, ODIW11;

  3. Import de los esquemas copiados

    imp userid=’system/xxx’ touser=ODIM11 fromuser=ODIM file=ODIM11.dmp

    imp userid=’system/xxx’ touser=ODIW11 fromuser=ODIW file=ODIW11.dmp

  4. Reconfigurar la conexión de ODI 11 a los nuevos esquemas ODIM11 y ODIW11 para comprobar que se hayan clonado correctamente.

Para ejecutar el upgrade, hay que ejecutar el fichero ua.bat (Upgrade Assistant) que se encuentra en la carpeta

    <Oracle_Middleware_Home>\oracle_common\upgrade\bin\ua.bat

de la instalación de ODI 12c. Para poder ejecutar el Upgrade Assistant es imprescindible instalar las parches que vienen con el installer de ODI 12c.

Leer más…

Categorías:BI Etiquetas: , , , , ,

ADF tips: Auditemos nuestros datos

En este tip comentaremos las opciones que nos brinda Oracle ADF para poder auditar la creación y modificación de datos. Contar con un sistema de auditoría de datos, en esta época en la que la seguridad y el saber quién y cuándo ha hecho qué, se  ha vuelto prácticamente imprescindible.

Para ello en ADF existen las “History Columns”, que se encargarán de almacenar debidamente la información para poder auditar nuestros datos. Cuando habilitamos este tipo de columnas será el framework el encargado de informarlas debidamente. El momento de asignación es durante la fase de “prepareForDML”.

Por defecto existen cinco tipos de columnas:

adf_tips_history_00

  • created on: Debe seleccionarse en un campo de tipo “Date” o “Timestamp”, una vez seleccionada la columna queda marcada como no actualizable nunca. El sistema almacenará la fecha y hora en la que el dato fue creado  (el valor es obtenido de la base de datos).
  • created by: Debe seleccionarse en un campo de tipo “String”, una vez seleccionada la columna queda marcada como no actualizable nunca. El sistema almacenará el nombre de usuario que creó la fila, para ello recupera al atributo “Principal” del contexto de seguridad (en caso de que no haya usuario se utilizará “anonymous”).
  • modified on: Debe seleccionarse en un campo de tipo “Date” o “Timestamp”. El sistema almacenará la fecha y hora en la que el dato fue modificado por última vez.
  • modified by: Debe seleccionarse en un campo de tipo “String”.  El sistema almacenará el nombre de usuario que modificó por última vez el dato.
  • version number: Debe seleccionarse en un campo de tipo “Long” o “Number”. Este campo indica el número de veces que este registro ha cambiado. En el momento de crearse el valor será 1, y con cada modificación irá aumentando.

Este tipo de columnas no pueden seleccionarse cuando el atributo en cuestión es parte de la clave primaria. Y además debemos no marcar las opciones de “Refresh After Update / Insert”, dado que si las marcaremos no servirá más que para ocasionar una pérdida de rendimiento o incluso almacenar datos incorrectos.

Estas opciones son las que nos brinda Oracle ADF por defecto, pero adicionalmente podemos definir columnas de auditoría personalizadas. Para ello tendremos que seguir los siguientes pasos:

  • Definir el tipo desde las opciones de JDeveloper:

adf_tips_history_01

  • Implementar el código asociado a nuestro tipo personalizado definiendo una constante que identifique nuestro tipo y sobreescribiendo el método getHistoryContextForAttribute:
private static final byte MY_AUDIT_COLUMN_HISTORY_TYPE = 11;

@Override
protected Object getHistoryContextForAttribute(AttributeDefImpl attr) {
    if (attr != null && attr.getHistoryKind() == MY_AUDIT_COLUMN_HISTORY_TYPE) {
        //Código de mi columna de auditoría personalizada.
    }else {
        return super.getHistoryContextForAttribute(attr);
    }
}
Categorías:ADF Etiquetas: , ,

Creación de servicios en bases de datos Oracle

Los servicios de base de datos permiten agrupar lógicamente las sesiones que se conectan a nuestra base de datos. Cada grupo presentará atributos, umbrales de nivel de servicio y prioridades comunes. De esta manera, se les puede aplicar diferentes políticas de recursos y perfiles a cada grupo. En una única BBDD podemos tener definidos múltiples servicios, que se ajusten a los diferentes tipos de aplicaciones que accedan a ella.

Las solicitudes de conexión a base de datos pueden incluir un nombre de servicio, vinculando todas las sesiones que usen esa conexión a ese servicio concreto.

Para gestionar servicios se puede utilizar el paquete DBMS_SERVICE. Aunque hay que tener en cuenta que si se tiene un entorno con alta disponibilidad que hace uso de clusterware, como RAC o Grid Infrastructure, es recomendable utilizar SRVCTL. En concreto, al dar un servicio de alta con DBMS_SERVICE no se actualiza el registro de cluster y éste, al desconocer la existencia del nuevo servicio, no lo puede gestionar (arrancar/parar junto con la BBDD), si lo creamos mediante SRVCTL el servicio queda registrado como un recurso mas a gestionar por el software de cluster.

A continuación vamos a poner un ejemplo de creación de dos servicios en una base de datos 11gR2 gestionada por Oracle Grid Infrastructure sobre ASM, uno de ellos con DBMS_SERVICE y el otro con SRVCTL.

Se puede comprobar la relación de los servicios existentes consultando una vista de base de datos como DBA_SERVICES o ALL_SERVICES, y se puede validar su estado desde línea de comando con la herramienta de control del listener ‘lsnrctl’.

Mediante DBMS_SERVICE se puede crear un servicio con el procedimiento CREATE_SERVICE y a continuación se puede arrancar con el procedimiento START_SERVICE.

En primer lugar comprobamos los servicios existentes:


SQL> select service_id, name, network_name, creation_date from dba_services;

SERVICE_ID NAME                 NETWORK_NAME         CREATION
---------- -------------------- -------------------- --------
         1 SYS$BACKGROUND                            24/08/13
         2 SYS$USERS                                 24/08/13
         3 dbtest2XDB           dbtest2XDB           23/01/14
         4 dbtest2.avanttic.com dbtest2.avanttic.com 23/01/14
         5 dbtest1XDB           dbtest1XDB           09/01/14
         6 dbtest1.avanttic.com dbtest1.avanttic.com 09/01/14

6 filas seleccionadas.

A continuación, creamos un servicio y comprobamos el listener:

Leer más…

Categorías:Database Etiquetas: , ,

Prueba real de integración de GoldenGate y Data Guard

En este post aportamos un ejemplo de integración de GoldenGate y Oracle Data Guard, aprovechando de cada uno sus mejores funcionalidades.

En primer lugar comentar que en ocasiones existen dudas sobre los usos “objetivo” de GoldenGate y Data Guard, en la siguiente gráfica podemos ver una descripción genérica de sus posibilidades.

gg_vs_sb

A grandes trazos, Data Guard nos aporta un entorno de recuperación ante desastres sólido y de alto rendimiento ideal para BBDD productivas críticas y con posibilidades de ser usado simultáneamente como entorno de bakup, reporting y pruebas.

GoldenGate por su parte es una herramienta de réplica heterogénea en tiempo real, de una enorme flexibilidad. Nos permite seleccionar de manera precisa los datos a replicar, enviar a cada destino solo los datos necesarios e incluso aplicar transformaciones en estos datos replicados. Todo ello sin ser intrusivo en las BBDD origen  y permitiendo replicas entre BBDD de diferentes tipos y fabricantes.

El cliente al que se le planteó esta arquitectura disponía en origen de un RAC productivo de 2 nodos y requería:

  1. Una solución de “Disaster Recovery” para su BBDD principal dentro del plan de “Bussines Continuity”. Este entorno de DR debería consistir en una réplica total de la BBDD en una ubicación remota, asegurando una pérdida de datos “cero” en caso de problemas.
  2. Descargar de su entorno principal ciertas selects realizadas por parte de sus clientes/proveedores. Un destino objetivo para estas selects eran BBDD en el “cloud”, por aportar flexibilidad y posibilidad de crecimiento bajo demanda.

La arquitectura planteada consistió en una BBDD Standby en un datacenter remoto replicada mediante Data Guard, así como la réplica de los datos necesarios para las selects mediante GoldenGate en BBDD remotas en el cloud. El siguiente esquema muestra la solución planteada:

solucion_planteada

Solución técnica:

  • La configuración de recuperación ante desastres con Data Guard consiste de un RAC de dos nodos en el CPD origen y una BBDD standby monoinstancia en el datacenter remoto.  La configuración mediante DataGuard permite conmutar el rol de las BBDD en unos pocos minutos, un alto rendimiento en la replica de la información y una perdida de datos “cero” en caso de problemas.
  • La BBDD que actúe como principal, independientemente de la que sea, está configurada para enviar la información de “redo” que genera además de a la correspondiente standby a una tercera BBDD que llamaremos “Downstream Database“.
  • En esta “Downstream Database” se ha configurado GoldenGate integrado con LogMiner para capturar los cambios de la BBDD productiva extrayendo estos del la información de “redo” recibida, la captura de datos por tanto no es un proceso intrusivo (no interfiere la BBDD principal para realizar la captura). Para optimizar más incluso el rendimiento se plantea configurar GoldenGate para capturar solo los datos del subconjunto de tablas implicado en las selects a externalizar (ignorando los cambios del resto de tablas).
  • Es el mismo GoldenGate quien, una vez capturados los cambios, los envía a las máquinas remotas y los aplica en sus respectivas BBDD. Las máquinas remotas sólo reciben el subconjunto de datos necesario para cada una de ellas, no todos los datos capturados. Las BBDD remotas pueden ser de fabricante, versión, arquitectura y dimensionamiento totalmente diferente a las originales, permitiendo ajustar su coste de mantenimiento al mínimo necesario para que realicen su cometido.
  • El cambio de roles de las BBDD principal/standby (sea mediante switchover o failover) no afecta el envío de los datos de redo a la BBDD de Downstream ni, por tanto, a la captura y aplicación de los cambios en las BBDD remotas. En caso de switchover/failover la réplica continua de manera trasparente sin necesidad de actuación por parte de los administradores.

Con esta configuración obtenemos todas las ventajas de Recuperación ante Desastres que nos aporta Data Guard así como una réplica trasparente, automática y no intrusiva de un subconjunto de datos a BBDD remotas de tipo “comodity” mediante GoldenGate.

Crónica Oracle Fusion Middleware Customer Showcase (Madrid, 2 julio)

El pasado día 2 de julio Oracle realizó un evento sobre la plataforma Oracle Fusion Middleware, totalmente centrado en mostrar experiencias y casos de éxito de clientes. Revisa aquí la agenda.

Entre las empresas que presentaron sus proyectos se encontraban 2 clientes de avantticSecuritas y Cetelem, que explicaron sus respectivas experiencias con Oracle SOA Suite y en especial con Oracle Service Bus.

En la última sesión del evento, 3 partners presentamos proyectos implantados con diferentes soluciones de la plataforma de middleware de Oracle.

200140702 Oracle Fusion Middleware avanttic

 

El proyecto presentado por avanttic (Javier Barrio, Socio Director) corresponde a un cliente del sector aeronáutico. Es un proyecto europeo de “oficina sin papel” para gestionar todo el ciclo de vida de la documentación relacionada con el diseño, la producción y el mantenimiento de cada nuevo modelo de aeronave. Las tecnologías Oracle utilizadas son WebCenter Content y Spaces, BPM, Database y ADF.

Contacta con nosotros si quieres conocer más detalles sobre los retos de este cliente y los beneficios que le ha aportado la solución que le hemos ayudado a desarrollar.

Revista Oracleando número 1 (SPOUG, junio 2014)

oracleando1El día 30 de junio se lanzó el primer número de la Revista Oracleando, publicada por SPOUG – Spain Oracle Users Group (“la evolución de CUORE”, el único grupo de usuarios reconocido por Oracle Spain).

avanttic es socio institucional de SPOUG y ha colaborado en este número con publicidad (contraportada) y con la publicación de un caso de éxito sobre el Ajuntament de Girona, en el que se explica cómo avanttic aportó su experiencia en la implantación de un proyecto de Disaster Recovery: para asegurar la continuidad del negocio, y la rápida recuperación de los datos en caso de desastre, la base de datos se replicó a un segundo CPD utilizando Oracle GoldenGate.

Además podrás encontrar, entre otros muchos artículos, una entrevista a Leopoldo Boado (Country Manager de Oracle Spain).

Desarrollos ADF: mono-plataforma vs multi-plataforma

adfUna decisión que hay que tomar a la hora de afrontar un proyecto en ADF es cómo y dónde vamos a desarrollar el código que soporte la lógica de negocio. Las dos posibilidades más obvias son:

  1. basar todo el desarrollo en Java, a nivel de aplicación, o
  2. implementar la lógica de negocio en PL/SQL en la base de datos, y usar java desde la aplicación para gestionar las capas de vista, controlador y modelo, dejando esta última capa como un mero acceso a BD.

Veamos las ventajas que aporta cada uno de los enfoques:

Ventajas desarrollo 100% ADF

  • Todo el equipo de desarrollo tiene el mismo perfil. No debemos buscar especialistas en java y especialistas en PL/SQL (o especialistas en ambas cosas a la vez). De todos modos, alguien tendrá que saber SQL.
  • Al tener un único origen de datos la gestión del control de versiones se simplifica.
  • Por el mismo motivo, los despliegues no incluyen scripts de compilación de objetos de base de datos (procedimientos, funciones, paquetes o triggers), además del fichero que desplegaremos en Weblogic.

Ventajas desarrollo ADF + PL/SQL

  • Los tiempos de desarrollo suelen ser menores, al ser PL/SQL un lenguaje de programación totalmente orientado al proceso de datos de BD.
  • Los procesos intensivos de datos son más eficientes y proporcionan mejores tiempos de respuesta.
  • Reutilización: al mantener la lógica de negocio junto a los datos, el impacto al cambiar el front-end es menor. Por ejemplo, si necesitamos llevar una parte de nuestra aplicación a una app móvil, no tendremos que volver a re-escribir código.
  • Podemos mantener los datos coherentes en cualquier caso, independientemente de la aplicación (por ejemplo totales de facturas basados en la suma de sus líneas; relaciones en arco; etc).

Encontraremos una ventaja añadida al desarrollo ADF + PL/SQL si pensamos en el largo plazo. Nuestra experiencia nos muestra que la base de datos suele ser el último componente que se descarta en el ciclo de vida de una aplicación. En este caso disfrutaremos durante más tiempo de la inversión que hayamos hecho escribiendo la lógica de negocio en BD.

Sin embargo hay quien opina justo lo contrario, que no se debe ubicar nada en la BD y que esta debe ser un puro contenedor de datos, de modo que se pueda cambiar de un gestor de BD a otro, pero… ¿conoces a alguien que haya cambiado?. Por supuesto, cualquier decisión en un sentido u otro debe tomarse tras un análisis mucho más detallado y tomando en consideración más factores que los pueden citarse en una entrada de blog.

Categorías:ADF Etiquetas: , ,
Seguir

Recibe cada nueva publicación en tu buzón de correo electrónico.

Únete a otros 127 seguidores