lunes, 28 de julio de 2008

Nuevo Blog

Hola a todos,

Hoy quiero presentaros un nuevo blog de un compañero mio que promete darnos bastante información, sobre todo útil, de CRM.

http://www.ms-dynamics-crm.blogspot.com/

Le deseo lo mejor

Salu2

martes, 1 de julio de 2008

10 best practices SSIS

En el post anterior he comentado algo sobre las 10 mejores prácticas de Integration Services. Via http://geeks.ms/blogs/elbruno/archive/2007/05/23/10-best-practices-para-sql-server-integration-services.aspx (el bruno) os indico cuales son:

  1. La Reutilización es una de las capacidades más aprovechadas dentro de SSIS. En otras palabras, podemos hablar de paquetes standards que pueden ser reutilizados en diferentes entornos de desarrollos ETL. Dentro de SSIS, esto puede lograrse utilizando templates. Los SSIS templates packages, son paquetes reutiilzables que pueden ser utilizados en cualquier proyecto una cantidad ilimitada de veces. Para más información consultar http://support.microsoft.com/kb/908018
  2. Es recomendavle evitar la utilización de puntos (.) en los nombres de los paquetes. La utilización de puntos se cruza con la nomenclatura de nombres que utiliza SQL Server y por lo tanto debe ser evitada. Un buen approach consiste en la utilización de guión bajo (_) en lugar de punto (.). Además es conveniente asegurarse que los nombres de los paquetes no excedan los 100 caracteres de largo. Durante el despliegue de los packages, los caracteres que excedan el largo de 100, serán quitados del nombre. Esto puede ocasionar que el SSIS package tenga errores durante el período de ejecucion, especialmente cuando se utiliza "Execute Package Tasks" dentro de otro paquete.
  3. El flujo de datos de en un paquete es una tarea intensiva para la memoria, en cada uno de los pasos y a nivel componente debemos revisar cuidadosamente que no estamos pasando columnas innecesarias en el flujo de datos. Esto ayuda en evitar tiempos adicionales del tiempo total de ejecución del paquete y adicionalmente mejora el funcionamiento total de la ejecución del paquete.
  4. Mientras se configura a cualquier conexion OLEDB como fuente, se debe evitar usar "Table or View" como el modo de acceso de los datos, éste es similar al "SELECT * FROM <TABLE_NAME>", y como la mayor parte de nosotros sabe, "SELECT *" es nuestro enemigo, esta sentencia toma en cuenta todas las columnas incluyendo las que incluso no se requieren. Intentar siempre utilizar el modo "SQL Command" como modo de acceso de los datos e incluir solamente los nombres de las columnas requeridas en la declaración "SELECT". De esta manera se evita pasar columnas innecesarias en flujo de datos.
  5. En los Data Flow Tasks, utilizar muy cuidadosamente el Flat File Connection Manager, crear un Flat File Connection Manager con la configuración por defecto utilizará el tipo de datos [DT_STR] por defecto para todos los valores de la columna. Ésta no es siempre la opción correcta porque porque puede existir algun tipo de dato numérico, número entero o columnas boleanas en la fuente, pasándolo como string en el flujo hacia abajo se utilizaría memoria innecesaria y puede causar cierto errores en las fases posteriores de la ejecución del paquete.
  6. El ordenar datos es una operación que consume mucho tiempo; en SSIS puedes ordenar los datos que vienen desde un componente superior utilizando un 'Sort transforming', no obstante esto es una tarea que consume mucha memoria y el resultado degrada el funcionamiento total de la ejecución del paquete. Como mejor práctica, en los lugares en donde sabemos que los datos están viniendo de las tablas de la base de datos SQL Server, es mejor realizar la operación de ordenar los mismos en motor de la base de datos utilizando una sentencia TSQL dentro del Query apropiado. Esto es mucho mejor porque el ordenamiento de datos en la base de datos es una tarea mucho mas refinada y depurada en SQL Server.
  7. Durante el desarrollo de los paquetes de SSIS, la mayor parte del tiempo uno tiene que compartir su paquete con otros miembros del equipo o uno tiene que desplegar el mismo paquete a cualquier otro desarrollador, UAT o entorno de producción. Una cosa que un desarrollador tiene que cerciorarse es utilizar el nivel correcto de la protección del paquete. Si alguien va con el nivel de la protección del paquete del defecto 'EncryptSenstiveWithUserKey' entonces el mismo paquete no pudo ejecutarse según lo esperado en otros ambientes porque el paquete fue cifrado con la llave personal del usuario. Para hacer la ejecución del paquete común a través de diferentes entornos, uno tiene que primero entender el comportamiento de la característica del nivel de la protección del paquete, es aconsejable leer http://msdn2.microsoft.com/en-us/library/microsoft.sqlserver.dts.runtime.dtsprotectionlevel.aspx. Generalmente, para evitar los errores mas comunes durante el despliegue de paquetes a partir de un sistema a otro sistema, fijar la protección del paquete a 'DontSaveSenstive'.
  8. Una buena práctica es utilizar Secuence Containers en paquetes de SSIS para agrupar diversos componentes en el 'Control Flow Level'. Esto ofrece_
    1. Proporciona un scope para las variables de un grupo de tareas relacionadas y de los contenedores que puede ser utilizado.
    2. Proporciona la facilidad para manejar las propiedades de múltiples tareas fijando la propiedad en el 'Secuence Container Level'
    3. Proporciona facilidad para definir el nivel de aislamiento de la transacción del sistema en el Container Level.
      Para más información sobre los envases de la secuencia, ver por favor http://msdn2.microsoft.com/en-us/library/ms139855.aspx.
  • Si estás diseñando una solución de ETL para una pequeña, media o grande parte del negocio de una empresa, siempre es bueno tener una característica que permita reiniciar los paquetes fallados a partir del punto de la falla. SSIS tienen una característica de fábrica llamada 'Checkpoint' para soportar el reinicio de paquetes fallidos desde el punto de la excepción. Sin embargo, es necesario configurar la característica del Checkpoint en el nivel del paquete. Para más información, ver http://msdn2.microsoft.com/en-us/library/ms140226.aspx.
  • Excecute SQL Task es nuestro mejor amigo en SSIS; podemos utilizar esto para ejecutar una declaración simple o múltiple de sentencias SQL a la vez. La belleza de este componente es que puede retornar resultados en diferentes formatos, por ejemplo: single row, full row set y XML. Puedes crear diversos tipo de conexiones usando este componente como OLEDB, ODBC, ADO, ADO.NET y SQL Mobile. Personalmente prefiero utilizar este componente la mayor parte del tiempo con mis sentencias FOR EACH para definir las iteraciones y verificar si ejecuto la tarea SQL. Para más información, ver http://msdn2.microsoft.com/en-us/library/ms141003.aspx y http://www.sqlis.com/58.aspx.
    1. Espero os sean de utilidad

      Salu2

      SSIS y Query Oracle con parametros

      O lo que es lo mismo "SSIS Query Oracle with parameters" :-)

      Escribo este post porque despues de pegarme mucho (muchiisimo) con SSIS (Integration Services) y Oracle para poder hacer una consulta en un OLEDBSource Task (Origen OLDB) con parámetros he conseguido encontrar la solución.

      Lo primero es crear una variable que contenga la consulta y tantas variables como parámetros. En propiedades indicar lo siguiente:
      - Evaluate as Expression en propiedades a True
      - Expression Property: "select xxx from xxx where job = '" + @[User::NbVariable] + "'"

      Por su parte el Origen OLDB lo configuraremos para que el access mode sea a SQL Command de Variable e indicaremos la variable definida anteriormente.

      Si pinchamos en vista previa veremos que nos devuelve los datos.

      el post que me ha ayudado.... http://forums.microsoft.com/TechNet/ShowPost.aspx?PostID=1530650&SiteID=17

      Curiosamente ademas es una de las 10 best practices

      Proximamente comentaré algo sobre ejecutar un paquete de SSIS en una maquina de x64 atacando a un oracle x64 sin el driver de Oracle OLEDB de x32

      Salu2