Conectar flujos de datos de Integration Services con bases de datos Oracle es muy sencillo, siempre que tengas bien configurado el driver de Oracle que te va a permitir esta conexión.

Los drivers que vienen por defecto no suelen funcionar bien para conectar con Oracle, y lo más recomendable es instalar y utilizar los conectores que proporciona Oracle, el famoso cliente de Oracle, tanto para trabajar con SQL Server Integration Services, como para crear aplicaciones directamente con Visual Studio..

Mantenerse actualizado es bueno y de vez en cuando va bien probar cosas nuevas que nos puedan permitir mejorar en algún aspecto de nuestro día a día. De vez en cuando me gusta ir viendo nuevas herramientas y tratar de seguir siendo proactivo para hacer mejor mi trabajo o al menos más cómodo. Anteriormente comente en otro post la existencia de un complemento de Apex llamado Refactor que permitía refactorizar para codificar de forma más clara y/o automática. En este post comento un poco el funcionamiento de una herramienta que se llama SQL Sentry Plan Explorer.  

Revisamos brevemente en este post la funcionalidad flashback query que aporta el gestor de BBDD de Oracle desde su versión 9i.

Básicamente se trata de un tipo de sql de Oracle que accede a datos que existían en la base de datos en un momento anterior, pero que en el momento en el que se ejecuta la sql pueden no existir o haber sufrido modificaciones. Para ello, Oracle utiliza los datos que quedan disponibles durante un tiempo en el segmento de UNDO. Este segmento almacena los datos anteriores a una serie de modificaciones. Se utiliza para asegurar la consistencia en la lectura de una consulta previa a la confirmación de las modificaciones (commit) y pueden ser utilizados en una posible recuperación (rollback).

En muchos proyectos relacionados con las tecnologías de la información es necesario introducir datos en los sistemas. Sean nuevos o se trate de una migración de los que había en un sistema a sustituir, la carga de los datos es una de las tareas que suele dar algún que otro dolor de cabeza si no se incluye como es debido en la planificación del proyecto.

Normalmente, los problemas vienen por la idea de que “los datos entran solos en las aplicaciones”. Nada más lejos de la realidad. Alguien los tiene que seleccionar, revisar, preparar y dar de alta en el sistema nuevo. Es una tarea que requiere una planificación específica ¿Quién lo debe hacer? ¿El proveedor o el cliente? ¿Un tercero?

Siguiendo con el post anterior creo necesario comentar que existen otros tipos de bloqueo que se producen por un diseño conflictivo que se une a las peculiaridades de oracle.

Dejo primero la traza de ejemplo:

Nos ponemos en situación
En nuestro entorno es posible que necesitemos disponer de dos replicas de una/s base de datos en entornos diferenciados (el clásico ejemplo sería producción y test). Para decidir como lo hacemos las preguntas más comunes que nos debemos hacer son:

-¿Este nuevo entorno será temporal? ¿Contiene bases de datos grande en cuanto a volumen y/o la carga que debe soportar es elevada(aunque sea test)?
-¿Dispongo de la versión de desarrollo de SqlServer2008? Que solo está a tu alcance si tienes una suscripción Msdn...
-¿Dispongo de un servidor adicional?...

Resumen

Para realizar una correcta auditoría de sistemas es necesario que los datos incluidos en las bases de datos posean calidad, por tal motivo es necesario analizar si es posible la detección de ruidos en una base de datos, utilizando una herramienta de visualización OLAP.

Para detectar ruido a través de técnicas de visualización OLAP¹ utilizamos una metodología Top-Down, intentando ir desde lo general a lo particular. De esta forma, en cada etapa vamos refinando cada vez mas la granularidad del ruido detectado, hasta lograr aislar cada tupla con ruido.