Guía de operaciones y optimización de SSIS

Artículo técnico de SQL Server

Autores: Alexei Khalyako, Carla Sabotta, Silvano Coriani, Sreedhar Pelluru, Steve Howard

Revisores técnicos: Cindy Gross, David Pless, Mark Simms, Daniel Sol

Fecha de publicación: diciembre de 2012

Se aplica a: SQL Server 2012; Base de datos SQL de Windows Azure

Resumen: SQL Server Integration Services (SSIS) se puede usar como herramienta para mover datos hacia y desde Base de datos SQL de Windows Azure (WA) como parte de la solución total de extracción, transformación y carga (ETL) y como parte de la solución de movimiento de datos. SSIS se puede usar para mover datos entre orígenes y destinos en la nube, y en un escenario híbrido entre la nube y una instancia local. En este documento se describen las prácticas recomendadas de SSIS para los orígenes y los destinos en la nube, se describe la planeación de proyectos de SSIS tanto si el proyecto está completamente en la nube como si implica movimientos de datos híbridos, y se recorre un ejemplo de cómo maximizar el rendimiento en un movimiento híbrido escalando horizontalmente el movimiento de datos.

Copyright

Este documento se proporciona "tal cual". La información y los puntos de vista que se proporcionan en este documento, incluidas las direcciones URL y otras referencias a sitios web de Internet, pueden sufrir modificaciones sin previo aviso. Usted acepta el riesgo de utilizarlo.

Algunos ejemplos descritos aquí se proporcionan con fines meramente ilustrativos y son ficticios. No se pretende ni debería deducirse ninguna asociación o conexión real.

En este documento no se proporciona ningún derecho legal de ninguna propiedad intelectual de ningún producto de Microsoft. Puede copiar y utilizar este documento para su propia referencia.

© 2011 Microsoft. Todos los derechos reservados.

2

ContenidoIntroducción................................................................................................................................................5

Diseño de proyectos....................................................................................................................................5

Ámbito y descripción de los problemas...................................................................................................5

Por qué el movimiento de datos es tan crítico en Azure.........................................................................6

Principales escenarios de movimiento de datos......................................................................................7

Carga inicial de datos y migración desde una instalación local a la nube............................................7

Mover datos generados en la nube a sistemas locales........................................................................8

Mover datos entre servicios en la nube...............................................................................................9

Herramientas, servicios y soluciones existentes......................................................................................9

SQL Server Integration Services (SSIS)...............................................................................................10

Clase SqlBulkCopy en ADO.NET.........................................................................................................11

Programa de copia masiva (BCP.EXE)................................................................................................12

Blobs y Colas de Almacenamiento de Azure......................................................................................12

Opciones de diseño e implementación..................................................................................................13

Diseñar e implementar una arquitectura equilibrada........................................................................14

Consideraciones sobre los tipos de datos..........................................................................................15

Empaquetado e implementación de una solución................................................................................15

Crear soluciones portátiles................................................................................................................15

Distribución de paquetes y componentes de código.........................................................................16

Base de datos SQL de Azure como destino de movimiento de datos................................................16

Consideraciones sobre la arquitectura......................................................................................................18

Diseñar para el reinicio sin perder el progreso de la canalización.........................................................18

El principio básico..................................................................................................................................18

Ejemplo con un único destino............................................................................................................19

Ejemplo con varios destinos..................................................................................................................25

Otras sugerencias para el reinicio..........................................................................................................27

Diseñar para el reintento sin intervención manual................................................................................28

Incorporar reintentos............................................................................................................................29

3

Opciones de optimización del rendimiento de SSIS...................................................................................33

Optimizar la configuración de red.........................................................................................................33

Configuración de red.........................................................................................................................34

Nota: al cambiar la configuración de la tarjeta de interfaz de red para usar tramas gigantes, asegúrese de que la infraestructura de red puede admitir este tipo de trama.................................34

Configuración del paquete SSIS.............................................................................................................35

Consideraciones especiales sobre los datos BLOB.............................................................................37

Usar características nuevas de SSIS 2012 para supervisar el rendimiento en un sistema distribuido. . .39

Registrar estadísticas de rendimiento...............................................................................................39

Ver estadísticas de ejecución.............................................................................................................41

Supervisar el flujo de datos...............................................................................................................47

Conclusión.................................................................................................................................................52

4

IntroducciónSQL Server Integration Services (SSIS) es una herramienta eficiente para mover datos hacia y desde Base de datos SQL de Windows Azure (WA) como parte de la solución total de extracción, transformación y carga (ETL) o como parte de la solución de movimiento de datos cuando no se necesita ninguna transformación. SSIS es eficiente para diversos orígenes y destinos, ya estén todos en la nube, sean todos locales o estén mezclados en una solución híbrida. En este documento se describen las prácticas recomendadas de SSIS para los orígenes y los destinos en la nube, se describe la planeación de proyectos de SSIS tanto si el proyecto está completamente en la nube como si implica movimientos de datos híbridos, y se recorre un ejemplo de cómo maximizar el rendimiento en un movimiento híbrido escalando horizontalmente el movimiento de datos.

Diseño de proyectosLos proyectos que mueven datos entre almacenes de datos en la nube y locales pueden implicar diversos procesos dentro de distintas soluciones. Suelen intervenir muchas piezas desde el rellenado inicial del destino, que puede tomar datos de otro sistema u plataforma, hasta el mantenimiento como el reequilibrio de conjuntos de datos entre números variables de particiones, y posiblemente la continuación con operaciones o actualizaciones masivas de datos periódicas. Normalmente, el diseño de un proyecto y los supuestos subyacentes de una solución que implica datos en la nube serán distintos en el caso de un entorno tradicional de movimiento de datos totalmente local. Muchas de las enseñanzas, experiencias y prácticas seguirán siendo aplicables, pero será necesario hacer cambios para contemplar diferencias como el hecho de que su entorno ya no es independiente y está completamente bajo su control a medida que cambia a un grupo compartido de recursos. Estas diferencias requieren el empleo de un enfoque más equilibrado y escalable.

Ámbito y descripción de los problemasTanto en el caso de soluciones nativas compiladas desde el principio para la nube como de soluciones migradas, es necesario mover datos de un sitio a otro. Probablemente esto ocurra en diversas fases del ciclo de vida de las aplicaciones. Las fases incluyen las pruebas previas a la producción, la carga inicial de datos, la sincronización de datos posterior entre los datos generados en la nube y las bases de datos locales originales, y la toma periódica de instantáneas de datos desde la nube hacia otros sistemas locales (por ejemplo, almacenamientos de datos).

5

Ilustración 1 Escenarios de movimiento de datos

Esta sección se centra principalmente es la fase inicial de carga de datos: considerar la experiencia completa de extracción de datos desde la base de datos de origen, pasar de local a la nube y cargar los datos en un destino final. Es importante resaltar que la mayoría de las prácticas recomendadas y las optimizaciones descritas en este documento, si no todas, se aplicarán por igual a la mayoría de los escenarios descritos con unos cambios mínimos. Hablaremos de estos escenarios y sus aspectos principales en las próximas secciones.

Por qué el movimiento de datos es tan crítico en AzureEn comparación con una experiencia de centro de datos tradicional, donde los desafíos que supone mover datos entre las aplicaciones y los sistemas suelen estar relacionados con aspectos tales como la compatibilidad de aplicaciones, la orquestación y la sincronización de procesos, y las capacidades de los recursos de hardware físicos y de red, en entornos en la nube como WA hay varios niveles adicionales de complejidad. La complejidad puede residir en áreas como la conectividad entre el ámbito local y la nube (o entre diferentes servicios en la nube) y puede estar relacionada con la confiabilidad, el ancho de banda y la latencia de conexión. Es fundamental tener en cuenta esta complejidad a la hora de desarrollar una solución óptima de movimiento de datos. Cuando en la solución participe un número elevado de elementos móviles, todavía es más importante centrar los esfuerzos en encontrar un diseño equilibrado entre todas las tecnologías y los componentes implicados. Procure no "sobrecargar" el eslabón más débil de la cadena porque esto afectará negativamente a todos los demás.

6

Base de datos SQL o SQL Server en una VM

Según las pruebas que hemos realizado, una de las áreas críticas es la capacidad del destino de datos para ingerir, a la velocidad adecuada, la cantidad de datos insertados desde el exterior. El enfoque más común consiste en escalar la base de datos de destino en varios nodos back-end mediante particionamiento personalizado (http://social.technet.microsoft.com/wiki/contents/articles/1926.how-to-shard-with-windows-azure-sql-database.aspx). Esta técnica será obligatoria si hay que cargar un volumen significativo de datos (en el momento de escribir este documento se considera significativo un volumen superior a 20 GB/hora) y se puede aplicar tanto a instancias de Base de datos SQL de Azure como a SQL Server que se ejecuta en máquinas virtuales (VM) de WA. Como esto no introducirá automáticamente escalabilidad lineal en la solución de carga de datos, cada vez es más necesario equilibrar los demás elementos móviles de la solución. En las próximas secciones se describen las áreas más críticas y las opciones de diseño que se pueden adoptar para maximizar el resultado final.

Principales escenarios de movimiento de datosA continuación se indican los tres escenarios principales que consideraremos parte de la experiencia completa global de movimiento de datos. Contendrán la mayoría de los temas y los desafíos recurrentes con los que nos encontraremos a lo largo del camino.

Carga inicial de datos y migración desde una instalación local a la nube Mover datos generados en la nube a sistemas locales Mover datos entre servicios en la nube

Carga inicial de datos y migración desde una instalación local a la nube

7

Ilustración 2 Escenario de carga inicial de datos

Toda aplicación que haya que mover desde una implementación local a un entorno en la nube requerirá también el movimiento de un determinado volumen de datos. Cuando el volumen de datos es importante, esta operación puede presentar algunos desafíos críticos que necesitarán un enfoque ligeramente diferente en comparación con lo que se estila en una implementación local. Esto se debe principalmente a dos áreas: el ancho de banda y la latencia de la red pública, y la cantidad de recursos (compartidos) necesarios para ejecutar la fase de carga de datos, que están disponibles en los nodos físicos de hardware que hospedan una base de datos (ya sea Base de datos SQL de Azure o VM de WA) en el entorno de nube. Existen métodos específicos (vea la ilustración 2) como el particionamiento de los datos originales en varios archivos de depósito y la compresión de estos archivos antes de transferirlos a través de la red que pueden ser útiles para minimizar el impacto que tiene el componente con el menor rendimiento sobre la solución global. El particionamiento de datos también será util en el lado de la nube para facilitar la inserción de estos datos en un destino de datos que es muy probable que esté repartido entre varias instancias de Base de datos SQL de Azure u hospedado en varias VM de WA.

SSIS desempeñará un papel importante tanto en el lado local como en la nube para ejecutar físicamente operaciones de importación y exportación. La solución global necesitará otras tecnologías como almacenamiento Blob y Colas de Azure para almacenar formatos de archivo intermedios y orquestar la operación de copia y recuperación en varias instancias de los procesos de importación de SSIS.

Para obtener más información relacionada específicamente con la migración de un esquema y de objetos de base de datos a Base de datos SQL de Azure, vea las instrucciones incluidas en Migrar aplicaciones centradas en datos a Windows Azure (http://msdn.microsoft.com/es-es/library/windowsazure/jj156154.aspx).

Mover datos generados en la nube a sistemas localesEste escenario es una pequeña variante del anterior, ya que desde una perspectiva técnica se trata de invertir el proceso de carga y el flujo de datos aunque puede haber algunas diferencias en cuanto a los objetivos globales. Este escenario suele asociarse a datos generados en frío que hay que recuperar y cargar periódicamente en sistemas locales como almacenamientos de datos, o a datos que alimentarán soluciones transaccionales locales. Esto significa que la mayoría de las técnicas y las tecnologías mencionadas en la sección anterior también serán pertinentes para este escenario. SSIS extraerá datos en el lado de la nube y, a continuación, los comprimirá y enviará de nuevo a un sistema local donde volverán a aplicarse las instrucciones tradicionales. Vea Guía de rendimiento de la carga de datos (http://msdn.microsoft.com/es-es/library/dd425070(v=SQL.100).aspx) para obtener más información.

8

Base de datos SQL o SQL Server en una VM

Mover datos entre servicios en la nubeHay varios escenarios en los que es necesario mover datos entre distintos servicios y bases de datos en la nube. Esto incluye el intercambio de datos entre distintas soluciones que necesitan interactuar entre

sí y la redistribución de datos repartidos entre tablas hospedadas en diferentes particiones como se muestra en la ilustración 3 que aparece a continuación.

Estas particiones pueden estar hospedadas por instancias de Base de datos SQL de Azure o por SQL Server en una VM de WA sin que ello afecte al método y la arquitectura subyacentes. Como diferencia respecto a los escenarios anteriores, todo el proceso de movimiento de datos tendrá lugar normalmente dentro de los límites de una única región de WA, lo que reduce considerablemente el impacto de la latencia de red y elimina la necesidad de exportar e importar datos mediante una ubicación de almacenamiento intermedio (discos locales o Almacenamiento de Azure). Si bien algunos escenarios pueden requerir mover datos entre distintas regiones, esa discusión queda fuera del ámbito del presente documento. Al mismo tiempo, como el origen y el destino de los datos estarán hospedados en un entorno compartido en la nube, aumentará drásticamente la necesidad de optimizar cuidadosamente la fase de carga en concreto.

Herramientas, servicios y soluciones existentesPara implementar soluciones que abordan los escenarios descritos anteriormente, se puede emplear una combinación de herramientas existentes y nuevas, y componentes y métodos que pueden ser útiles tanto en implementaciones locales como en la nube. En un entorno híbrido, algunos de estos componentes tendrán que ubicarse con sistemas y orígenes de datos existentes locales, mientras que será mejor colocar otros componentes con destinos de datos en la nube.

9

Ilustración 3 Mover datos entre particiones de base de datos

SQL Server Integration Services (SSIS)Como solución principal de movimiento e integración de datos, SSIS proporciona una gran variedad de funciones que abarcan la mayoría de las áreas necesarias en estos escenarios. Si bien no están diseñados específicamente para el entorno híbrido, con la llegada de las VM de WA, los paquetes SSIS se pueden ejecutar tanto de forma local como en la nube, y podrían conectar directamente los dos mundos. Esto abre la puerta a gran cantidad de reutilización de conocimientos y cualificaciones en la comunidad de desarrolladores de DBA/ETL, debido al elevado número de profesionales existentes que se han entrenado y expuesto a esta tecnología; sin embargo, es importante entender que no todos los procesos existentes de ETL implementados mediante SSIS se pueden reutilizar directamente al mover datos de una implementación local a la nube.

En función de la complejidad, el volumen de datos y la velocidad del proceso, así como de las diferencias intrínsecas entre los destinos de datos basados en la nube como SQL Server que se ejecuta en una VM de WA y Base de datos SQL de Azure, serán necesarios algunos cambios de diseño.

Algunos de estos desafíos pueden estar relacionados con la falta actual de capacidades para tratar las realidades de conexión de la nube cuando se conecta a Base de datos SQL de Windows Azure o con la cantidad de trabajo necesario para diseñar paquetes SSIS que tienen que tratar con errores y reintentos durante los procesos de carga de datos.

Otro problema puede ser el diseño de paquetes que tienen que conectarse a destinos de datos con particiones (particionados), donde las entidades de base de datos pueden estar repartidas entre un número a veces cambiante de nodos físicos. La lógica y los metadatos de particionamiento tienen que administrarse y recuperarse desde archivos de configuración o estructuras de datos de la aplicación.

La plataforma SSIS ya cuenta con la mayoría de las capacidades para afrontar estos desafíos. Por ejemplo, se pueden usar componentes de Flujo de datos como las transformaciones División condicional y Multidifusión para implementar la lógica de particiones.

Al abordar cualquiera de los desafíos de la arquitectura, habrá que realizar algún esfuerzo para implementar de manera práctica el nuevo diseño, ya sea con el enfoque tradicional de herramientas visuales o de una forma más automatizada y mediante programación de diseñar una solución más compleja. Para el enfoque de programación, SSIS ofrece un entorno que admite scripting y que abarca desde la creación de tareas personalizadas dentro de la canalización de transformación hasta la instrumentación del motor que ayuda a solucionar problemas y depurar la ejecución de paquetes.

Como parte de la versión de SQL Server 2012 de Integration Services, una solución completa de supervisión y administración basada en un catálogo común puede ayudarle a diseñar una solución distribuida de movimiento de datos y a recopilar información sobre las estadísticas y los resultados de la ejecución de paquetes.

10

Clase SqlBulkCopy en ADO.NETSi el desarrollo de una solución personalizada de movimiento de datos es el método preferido para resolver un problema determinado de movimiento de datos, probablemente la clase SqlBulkCopy (http://msdn.microsoft.com/es-es/library/system.data.sqlclient.sqlbulkcopy.aspx) de la biblioteca de acceso a datos de ADO.NET sea una de las herramientas más habituales para ello. Esta clase, creada como un fino contenedor alrededor de las API de copia masiva de ODBC, aceptará una tabla de datos como entrada y una conexión de base de datos existente, y ofrecerá una manera rápida y totalmente configurable para cargar datos en SQL Server o en Base de datos SQL de Azure.

Un aspecto importante del uso de la clase SqlBulkCopy para interactuar con un destino de datos en la nube es la posibilidad de reemplazar fácilmente la clase SqlConnection (http://msdn.microsoft.com/es-es/library/system.data.sqlclient.sqlconnection.aspx) tradicional empleada para interactuar con el servidor con la clase ReliableSqlConnection (http://msdn.microsoft.com/es-es/library/microsoft.practices.enterpriselibrary.windowsazure.transientfaulthandling.sqlazure.reliablesqlconnection(v=pandp.50).aspx), más apropiada, que forma parte de la biblioteca de Bloqueo de aplicación para la administración de errores transitorios (http://msdn.microsoft.com/es-es/library/hh680934(v=PandP.50).aspx). Esto simplifica en gran medida la tarea de implementar un mecanismo de lógica de reintento en un proceso de carga de datos nuevo o existente. Otro faceta interesante de la biblioteca es la capacidad de proporcionar directivas de reintento estándar y personalizadas para adaptarse fácilmente a las distintas condiciones de conectividad.

La clase SqlBulkCopy expone todas las propiedades y los atributos necesarios para poder adaptar el proceso de carga a casi todas las condiciones posibles. En este artículo se explicará cómo ajustar y optimizar los tamaños de lote según dónde se vaya a ejecutar el proceso de carga de datos, cuántos datos tenga que importar el proceso y el tipo de conectividad que habrá disponible entre el proceso y el destino de datos.

Una situación en la que la clase SqlBulkCopy no sería la elección más eficiente para cargar datos en un destino es cuando la cantidad de datos de un solo lote es muy baja, por ejemplo entre 10 y 1000 filas por lote. En este caso, la sobrecarga que impone la clase SqlBulkCopy para establecer la comprobación inicial de los metadatos antes de que comience la carga de datos puede afectar al rendimiento global. Un buen método alternativo para los lotes pequeños consistiría en definir un parámetro con valores de tabla (TVP) que implemente el esquema deseado y usar “INSERT INTO Destination SELECT * FROM @TVP” para cargar los datos.

Para obtener un ejemplo completo del uso de la API de copia masiva, vea SqlBulkCopy (Clase) (http://msdn.microsoft.com/es-es/library/system.data.sqlclient.sqlbulkcopy.aspx).

11

Programa de copia masiva (BCP.EXE)Hace tiempo que se usa el programa de copia masiva (una utilidad de línea de comandos creada con las mismas API de copia masiva descritas para la clase SqlBulkCopy) para realizar la carga masiva de datos hacia y desde una instancia de SQL Server. El programa es una herramienta simple pero eficaz para automatizar de forma eficiente soluciones simples de movimiento de datos. Una de las ventajas principales de la herramienta es que es muy fácil automatizar su instalación en nodos de proceso o en VM de Azure y usar fácilmente scripts existentes que se pueden adaptar para su ejecución en un entorno de nube.

Por otra parte, BCP.EXE no proporciona ninguna capacidad avanzada de administración de la conexión. Además, BCP.EXE necesita el mismo esfuerzo que SSIS para implementar tareas confiables de movimiento de datos basadas en operaciones de reintento que pueden producir inestabilidad y pérdida de la conexión. Asimismo, a diferencia de las demás herramientas mencionadas, BCP.EXE tiene que importar o exportar datos de archivos físicos hospedados en una unidad local, asignada o conectada. Esto hace imposible la transmisión de datos por secuencias desde el origen al destino directamente, o la lectura mediante programación de datos de orígenes diferentes como puede hacer SSIS o una aplicación basada en SqlBulkCopy.

Blobs y Colas de Almacenamiento de AzureSi bien no se trata de herramientas relacionadas estrictamente con el movimiento de datos, las capacidades de Almacenamiento de Azure son esenciales para implementar soluciones complejas que necesitan almacenamiento intermedio entre los procesos locales y en la nube, y para poder orquestar fases y operaciones entre los dos entornos. Los blobs de Almacenamiento de Azure representan un mecanismo eficaz de almacenamiento para cargar archivos intermedios, y para intercambiar estos archivos entre nodos de proceso o VM de Azure y aplicaciones que se ejecutan de forma local. Las Colas de Almacenamiento de Azure representan una herramienta simple de mensajería que se puede usar para notificar y coordinar el acceso a archivos y a contenido almacenado como Blobs de Azure, desde procesos de carga de datos.

Los Blobs y las Colas de Almacenamiento de Azure son fáciles de integrar en las aplicaciones existentes gracias a la biblioteca cliente de Almacenamiento de Azure .NET que ofrece un conjunto simple de clases para interactuar con cuentas, contenedores y blobs de Almacenamiento, y con otras operaciones relacionadas. Esta biblioteca oculta los detalles de la interfaz subyacente basada en REST, y ofrece un puente entre datos locales y en la nube. Para obtener más información sobre cómo usar Colas y Blobs de Almacenamiento de Azure, vea Cómo usar el servicio de almacenamiento Cola (http://www.windowsazure.com/en-us/develop/net/how-to-guides/queue-service/) y Cómo usar el servicio de almacenamiento Blob de Windows Azure en .NET (http://www.windowsazure.com/en-us/develop/net/how-to-guides/blob-storage/).

12

Opciones de diseño e implementaciónHay varios factores que pueden afectar a las opciones de diseño e implementación de soluciones híbridas de movimiento de datos. Probablemente la necesidad de reutilizar artefactos y procesos existentes en lugar de empezar con una hoja en blanco sea lo que más influya en las decisiones de diseño, seguido de los conocimientos necesarios y los perfiles de los miembros del equipo (por ejemplo, si se dispone de más desarrolladores que DBA). ¿Cuenta el equipo con los conocimientos necesarios para generar una solución completamente personalizada mediante programación o para adaptar procesos de ETL existentes? En cualquier caso, hay algunos aspectos que hay que tener en cuenta cuando se incluye la nube en el diseño porque algunos de los supuestos obvios que se hacen sobre los entornos locales tradicionales pueden no ser válidos en un entorno en la nube.

Otro aspecto de diseño importante es dónde colocar y ejecutar determinados servicios y tareas de movimiento de datos, como la lógica de división condicional que realiza actividades de compresión o particionamiento de los datos. Según cómo se implementen estas tareas en el nivel de componente (canalización de SSIS o tareas personalizadas), estos componentes pueden consumir mucha CPU. Para equilibrar el consumo de recursos, quizás tenga sentido mover las tareas a VM de Azure y aprovechar la elasticidad natural de ese entorno en la nube. Al mismo tiempo, la proximidad a los orígenes de datos sobre los que operarán puede proporcionar incluso más ventajas debido a la menor latencia de red, que puede ser realmente crítica en este tipo de solución. El planeamiento y las pruebas ayudarán a determinar cuellos de botella de recursos concretos, y guiarán las decisiones sobre cómo implementar diversas tareas.

Los esfuerzos necesarios para implementar o adaptar una solución existente en un escenario híbrido tienen que estar justificados por los beneficios que el escenario híbrido puede proporcionar. Es necesario aclarar las ventajas técnicas que se consiguen moviendo algunas partes de la solución a la nube frente al conjunto de elementos que se pueden perder parcialmente para lograr un modo de pensar correcto y realizar correctamente una implementación híbrida. Esos compromisos están relacionados con aspectos muy tangibles del diseño de una solución. ¿Cómo puedo aprovechar las capacidades masivas de escalado horizontal que proporcionan las plataformas en la nube sin perder demasiado control sobre los componentes de la solución? ¿Cómo puedo ejecutar mis procesos de carga de datos en una plataforma que está diseñada para escalado horizontal en lugar de vertical y seguir proporcionando un rendimiento aceptablemente predecible? Para abordar estas preguntas es necesario abandonar algunos supuestos sobre el rendimiento y la confiabilidad de la conectividad de red, y los componentes y servicios de aplicación que siempre están activos, y en su lugar planear pensando en los recursos que se pueden agregar para resolver los problemas de rendimiento. Se debe entrar en un mundo en el que es necesario diseñar pensando en el error, la latencia suele ser más alta que en su experiencia anterior y es muy conveniente repartir una carga de trabajo entre muchas máquinas virtuales o servicios pequeños.

13

Diseñar e implementar una arquitectura equilibradaTodas estas consideraciones deben guiarnos en la dirección correcta a la hora de diseñar una solución compleja de movimiento de datos con varios elementos móviles, donde ninguno de ellos representa necesariamente el equivalente "mejor" en los componentes locales tradicionales.

Este debe ser el principio rector: desglose el proceso de movimiento de datos en varios elementos menores, desde la extracción del origen de datos hasta la carga en el destino de los datos, que tienen que ser asincrónicos y estar orquestados para adaptarse al entorno de mayor latencia que introduce la solución híbrida. La búsqueda del equilibrio adecuado entre todos los componentes de un entorno será mucho más importante que la consecución del grado de pureza (los límites) de un único componente. Puede que incluso los pasos individuales de este proceso, como la carga de datos, tengan que repartirse en secuencias de carga menores que abarquen diferentes particiones o bases de datos físicas, para superar las limitaciones de un único nodo back-end en nuestra arquitectura de Base de datos SQL de Azure.

Debido a la naturaleza de alta disponibilidad, compartida y multiempresa de algunos componentes de nuestro sistema (los nodos de Base de datos SQL de Azure y el repositorio de blobs de Almacenamiento de Azure para una VM de WA que hospeda SQL Server), la inserción de demasiados datos en un único nodo puede ocasionar problemas de rendimiento adicionales. Un ejemplo de los problemas de rendimiento es inundar el mecanismo de replicación, lo que hace que todo el proceso de carga de datos sea más lento.

Ilustración 4 Representación esquemática de una arquitectura equilibrada de carga de datos

14

Consideraciones sobre los tipos de datosEl esquema de la base de datos, el diseño de las entidades y los tipos de datos usados pueden afectar al proceso de movimiento de datos de muchas formas. Como regla general, los tipos de datos que pueden alcanzar un mayor grado de compresión pueden proporcionar varias ventajas cuando los datos se cargan de forma masiva desde sus orígenes en Blobs de Azure o en almacenamiento local para las operaciones temporales. Por supuesto, la compresión de datos antes de su transferencia mejora el rendimiento.

Empaquetado e implementación de una soluciónImplementar e implementar una solución que abarca centros de datos locales y entornos basados en la nube significa normalmente que hay que ocuparse de varios componentes y servicios. Proporcionar un alto nivel de automatización tanto en la implementación como en la configuración de todos estos elementos es incluso más importante si piensa implementar varias instancias de la solución de movimiento de datos. Las tecnologías de virtualización pueden ayudar a crear una imagen maestra. La imagen maestra se podría usar tanto de forma local como en la infraestructura de VM de Azure para simplificar la implementación de servicios comunes que deben estar presentes en ambos entornos.

Al mismo tiempo, el trabajo con las VM de WA impone algunas limitaciones en comparación con lo que pueden proporcionar otros nodos de proceso de Azure como los roles web y los roles de trabajo, tanto en cuanto a los paquetes y servicios de aplicación como a los correlacionados (por ejemplo, piense en las tareas de inicio).

Si ya está aprovechando capacidades de distribución de software, como las que están disponibles en las familias de productos Windows Server y System Center, otra posibilidad sería distribuir los componentes y los paquetes de la solución con algunos componentes que se ejecutan en la nube y otros que se ejecutan en entornos locales.

Otra posibilidad consiste en instalar y configurar manualmente los diferentes componentes de la solución como SSIS y Azure SDK (para tener acceso a las capacidades de Almacenamiento de Azure), así como todos los paquetes de instalación de la aplicación (.msi) necesarios en cada VM que se ejecutará como parte del entorno distribuido.

Crear soluciones portátilesUn aspecto que será cada vez más importante cuando ejecute una solución en una arquitectura de escalado horizontal es la posibilidad de reconfigurar rápidamente opciones como cadenas de conexión, credenciales y todas las demás opciones de configuración que incluirá la solución. Para ello suele ser necesario emplear algún tipo de mecanismo centralizado de configuración, en el que se tenga acceso a la información y se propague a todos los componentes y servicios implicados en el proceso de movimiento de datos para asegurarse de que cada cambio requiere el mínimo esfuerzo. Las herramientas estándar como SSIS, y los componentes y las aplicaciones desarrollados de forma personalizada, se pueden implementar fácilmente con este enfoque en mente. El almacenamiento de Azure puede ser una buena opción para guardar y mantener la información de configuración, ya que es fácilmente accesible y está disponible para los componentes locales y en la nube.

15

Merece la pena destacar que la plataforma de SSIS ya incluye varias características que simplifican el transporte y el escalado de una solución, como los archivos y parámetros de configuración. Los procesos y servicios adicionales que conforman la solución completa de movimiento de datos pueden implementar los mismos tipos de enfoques configurables, facilitando el traslado de la solución entre diferentes entornos.

Distribución de paquetes y componentes de códigoUna vez que se han implementado todos los elementos de la solución, el proceso que elija para distribuir físicamente los distintos paquetes SSIS y componentes de código entre diversos equipos es fundamental. Otro aspecto, incluso más importante, será cómo se hospedarán y ejecutarán estos paquetes y elementos de código dentro de los distintos servidores y VM. Si bien el entorno nativo de SSIS en SQL Server 2012 ofrece distintos tipos de almacenamiento y modelos de implementación de paquetes, el desarrollo de una solución completa de movimiento de datos puede requerir opciones de diferencia. Si necesita ejecutar algunos servicios o aplicaciones de orquestación para supervisar y controlar el proceso de movimiento de datos, ¿cómo se pueden implementar estos servicios o aplicaciones? Y ¿qué cantidad de la infraestructura subyacente de SSIS puede emplear? En las notas del producto "SQL Server 2012 SSIS para Azure y movimiento de datos híbridos" se ofrece un ejemplo específico de distribución y coordinación de los componentes. Este documento se encuentra en MSDN Library, en el nodo Notas del producto de Microsoft para SQL Server 2012.

Las VM de WA y los servidores físicos basados en Windows Server no implementan algunas de las características que la plataforma Azure proporciona para los roles web y los roles de trabajo. Por tanto, lo mejor es implementar esos componentes como servicios de Windows, para asegurarse de que los procesos se iniciarán cuando los diversos hosts arranquen y continuarán ejecutándose independientemente de una sesión de usuario interactivo en ese equipo concreto. La plataforma .NET simplifica enormemente la creación y el empaquetado de este tipo de paquete de software que se puede distribuir e implementar en los diversos hosts mediante las opciones que se han descrito anteriormente.

Los servicios y las aplicaciones de orquestación interactúan con los distintos componentes externos (Almacenamiento de blobs de Windows Azure, Colas, etc.), invocan el motor de ejecución de SSIS (DtExec.exe), y orquestan las tareas de carga y transformación de datos en varios hosts o VM.

Los componentes personalizados que la ejecución del paquete necesita también deberán distribuirse en varios nodos.

Con este enfoque distribuido, se puede crear un entorno de implementación y ejecución sólido, portátil y flexible para hospedar nuestra solución completa de movimiento de datos en una infraestructura totalmente híbrida.

Base de datos SQL de Azure como destino de movimiento de datosSi bien SQL Server y Bases de datos SQL de Windows Azure presentan algunas similitudes, es un error considerarlos idénticos. Existen varias diferencias que pueden afectar al rendimiento de las aplicaciones en Base de datos SQL de Windows Azure en comparación con una base de datos de SQL Server.

16

Base de datos SQL de Windows Azure es un servicio hospedado que implementa una arquitectura totalmente multiempresa. A diferencia de las implementaciones tradicionales de SQL Server, Base de datos SQL de Windows Azure contiene características alta disponibilidad (HA) integrada y copias de seguridad automáticas, y se ejecuta en hardware estándar en lugar de en grandes servidores. La base de datos ejecuta un subconjunto de las características usadas habitualmente en entornos locales, incluidas compresión de base de datos, consultas en paralelo, índices de almacén de columnas, particionamiento de tablas, etc. Para obtener más información acerca de las limitaciones de características para Base de datos SQL de Windows Azure, vea Limitaciones de las características de SQL Server (Base de datos SQL de Windows Azure) (http://msdn.microsoft.com/es-es/library/windowsazure/ff394115.aspx).

Una de las mayores diferencias entre Base de datos SQL de Windows Azure y SQL Server es que Base de datos SQL de Windows Azure expone un servicio multiempresa de escalado horizontal, donde cada una de las distintas suscripciones comparte los recursos de uno o varios equipos de un centro de datos de Microsoft. El objetivo es equilibrar la carga global dentro del centro de datos moviendo de vez en cuando los clientes por equipos diferentes. Estos equipos son servidores estándar en bastidores, lo que maximiza la relación precio/rendimiento en lugar del rendimiento total. No todos los nodos de Base de datos SQL de Windows Azure usarán hardware sumamente avanzado en su oferta hospedada.

Cuando una aplicación cliente necesita superar los límites de un único equipo, se debe modificar la aplicación para repartir la carga de trabajo de los clientes entre varias bases de datos (lo que significa varios equipos) en lugar de usar un único servidor. Una de las desventajas de la elasticidad y la facilidad de uso de este entorno es que en ocasiones la aplicación se puede mover a otro equipo de forma inesperada. Como las sesiones no tienen estado, el diseño de la aplicación debe emplear técnicas que impidan puntos de error únicos. Esto incluye el almacenamiento en memoria caché en otras capas cuando sea necesario, y el uso de lógica de reintento al conectarse y comandos resistentes a errores.

Además, las distintas capas de una infraestructura de WA no van a estar en la misma subred de la red, por lo que habrá algunas diferencias de latencia entre las aplicaciones cliente y Base de datos SQL de Windows Azure. Esto es cierto incluso cuando las aplicaciones y la base de datos se hospedan en el mismo centro de datos físico. Las soluciones tradicionales de carga de datos de SQL Server que son muy 'locuaces' pueden ejecutarse más despacio en Windows Azure debido a estas diferencias físicas de red. Para aquellos que estén familiarizados con la informática cliente-servidor anterior, aquí se aplican las mismas soluciones: medite concienzudamente sobre las operaciones de ida y vuelta entre las capas de una solución para controlar cualquier diferencia visible en la latencia.

17

Consideraciones sobre la arquitecturaAlgunos de los desafíos más frecuentes que plantean los paquetes SSIS residen en cómo controlar los errores inesperados durante la ejecución y cómo minimizar el tiempo necesario para finalizar la ejecución de un proceso de ETL cuando se debe reanudar el procesamiento después de un error. Para las tareas de flujo de control como las tareas del sistema de archivos, se pueden usar puntos de comprobación para reanudar la ejecución sin volver a procesar lo que ya se ha completado. Para obtener instrucciones completas sobre cómo usar puntos de comprobación, vea Reiniciar paquetes usando puntos de comprobación (http://msdn.microsoft.com/es-es/library/ms140226.aspx).

A menudo, el flujo de datos es la parte mayor del paquete SSIS. En esta sección, verá estrategias de diseño de paquetes para permitir un reintento automático después de un error y de diseño de la canalización de flujo de datos para permitir la recuperación desde el punto de error en lugar de reintentar todo el flujo de datos.

En las notas del producto "SQL Server 2012 SSIS para Azure y movimiento de datos híbridos" se tratan otras consideraciones adicionales sobre el control de errores transitorios en la plataforma de WA. Este documento se encuentra en MSDN Library, en el nodo Notas del producto de Microsoft para SQL Server 2012.

Diseñar para el reinicio sin perder el progreso de la canalizaciónAl diseñar paquetes, una de las mayores preocupaciones es el diseño de forma que, en caso de que se produzca un error, no se pierda todo el progreso que ha realizado el paquete haste ese momento. En el caso de los elementos del flujo de control de un paquete, esto se logra mediante el uso de puntos de comprobación. Sin embargo, poder reiniciar un flujo de datos sin perder el progreso realizado es algo que solo se puede conseguir mediante el diseño del paquete. En esta sección, verá una estrategia para diseñar paquetes que permite el reinicio del flujo de datos desde el punto de error y que permite que el paquete realice automáticamente un reintento para que no se produzcan errores si se pierde una conexión. Cuando se mueven datos hacia o desde Base de datos SQL de WA, es especialmente importante planear esas caídas o breves interrupciones de conexión.

El principio básicoSi bien el rendimiento es importante en cualquier movimiento de datos, debe alcanzar un equilibrio entre los requisitos de rendimiento y la cantidad de progreso que puede permitirse perder si ocurre algo durante el movimiento de datos.

En cada movimiento de datos, debe disponer de alguna forma de saber qué datos han llegado ya a su destino y cuáles no. En el caso de los datos que solo se se insertan, normalmente se puede determinar solo con la clave principal. En el caso de otros datos, puede ser la fecha de última modificación. Cualquiera que sea la naturaleza de los datos, la primera parte del diseño para el reinicio es entender cómo identificar los datos ya existentes en el destino, qué datos se deben actualizar en el destino y qué datos hay que entregar todavía al destino. Una vez establecido esto, puede segmentar y ordenar los datos de forma

18

que pueda procesar únicamente los datos que no han llegado al destino o minimizarr la cantidad de repetición del trabajo que hay que realizar en cualquier fase.

La fragmentación y la ordenación le permiten hacer fácilmente un seguimiento de qué fragmentos se han procesado y con la ordenación puede hacer un seguimiento de los registros de cualquier fragmento que ya se han procesado. Según este enfoque, no es necesario comparar todas las filas de origen con el destino para saber si se ha procesado ese registro.

Otros procesos de ETL más complejos pueden tener varios entornos de ensayo. Cada entorno de ensayo es un destino de una fase de ETL. En estos tipos de entornos, considere cada entorno de ensayo como un destino independiente y diseñe cada segmento de ETL para el reinicio.

Ejemplo con un único destinoEl flujo de datos reiniciable más simple es uno pequeño con un solo entero como clave principal. Cuando SQL Server es el origen, puede consultar este origen mediante la práctica recomendada de limitar los datos que extrae del origen. Considere la tabla de ejemplo clásica de AdventureWorks: "Production.TransactionHistory". La tabla tiene la estructura siguiente:

CREATE TABLE [Production].[TransactionHistory](

[TransactionID] INT NOT NULL PRIMARY KEY,[ProductID] INT NOT NULL,[ReferenceOrderID] INT NOT NULL,[ReferenceOrderLineID] INT NOT NULL,[TransactionDate] INT NOT NULL,[TransactionType] NCHAR(1) NOT NULL,[Quantity] INT NOT NULL,[ActualCost] MONEY NOT NULL,[ModifiedDate] DATETIME NOT NULL,

)

En este ejemplo, la tabla tiene un único entero como clave principal. Si los datos son estáticos en el momento del movimiento de datos, o si los datos solo se insertan en esta tabla (sin actualizaciones), todo lo que necesita para saber si una fila ha llegado o no al destino es la clave principal. La comparación de todos los valores de clave principal con el destino será relativamente costoso. En su lugar, emplee una estrategia de ordenar los datos del archivo de origen por la columna TransactionID.

Con esa estrategia, lo único que necesita saber es que los datos se han procesado en orden y cuál es el mayor valor de TransactionID que se ha confirmado en el destino.

En un paquete SSIS, puede hacerlo de la manera siguiente.

1. Compruebe la clave más alta en el destino.2. Cree la consulta desde el origen para extraer únicamente los registros cuyo valor de

TransactionID sea mayor que el máximo valor de TransactionID en el destino.3. Use ORDER BY TransactionID en la consulta de origen para asegurarse de que la comparación

del mayor valor de TransactionID sigue siendo válido la próxima vez que inicie el paquete.

19

En SSIS, cuando se usa un origen de datos relacional como origen, puede usar una tarea Ejecutar SQL para extraer el valor máximo en una variable en el paquete. Sin embargo, debe considerar la posibilidad de que no exista ninguna fila en el destino.

SELECT MAX(TransactionID) FROM Production.TransactionHistory

Para recuperar el valor máximo de TransactionID, considere que el resultado de una tabla vacía será NULL. Esto puede producir algunos problemas en la lógica que se usa en un paquete. Una solución mejor es usar primero una tarea Ejecutar SQL en el origen y buscar el valor mínimo de TransactionID sin procesar en el origen. A continuación, consulte el valor máximo de TransactionID del destino; si no existe ninguno, use un valor inferior al valor mínimo de TransactionID del origen. Cree la consulta de origen para extraer únicamente los registros mayores que este valor y no olvide usar ORDER BY TransactionID en la consulta.

NOTA: aunque lógicamente obtendrá los mismos resultados si simplemente recupera un valor del destino y emplea una función ISNULL, o una instrucción CASE en la cláusula WHERE de la consulta de origen, esto puede producir problemas de rendimiento, sobre todo cuando las consultas de origen adquieren mayor complejidad. Resista el impulso de tomar este atajo. En su lugar, busque un valor que pueda usar de forma segura como límite inferior y cree la consulta de origen usando ese valor.

NOTA: cuando el origen es SQL Server, el uso de una cláusula ORDER BY en un índice clúster no hace que SQL Server realice trabajo adicional para la ordenación. Los datos ya están ordenados de manera que se puedan recuperar sin realizar una ordenación (SORT). Si los datos del destino tienen también un índice clúster en la misma columna, la ordenación en el origen optimiza la consulta de origen y también optimiza las inserciones en el destino. Otro efecto que tiene es garantizar el orden dentro de la canalización de SSIS, lo que permite poder reiniciar el flujo de datos en el punto de error.

Para generar este paquete de ejemplo, haga lo siguiente.

1. Cree un nuevo paquete en un proyecto nuevo o existente. Cambie el nombre del paquete a “SimpleRestart”.

2. Cree administradores de conexiones para conectar con el origen y el destino. En este ejemplo, se crea un administrador de conexiones OLE DB para los servidores de origen y de destino.

3. Arrastre una nueva tarea Ejecutar SQL hasta la superficie del flujo de control y cambie su nombre a “Pull Min TransactionID From Source”.

4. Cree una variable de SSIS en el nivel de paquete y asígnele el nombre minTransactionIDAtSource. Usaremos esta variable para almacenar el valor que extraiga de la tarea Ejecutar SQL recién agregada. Asegúrese de que el tipo de datos sea Int32 para que coincida con el valor de TransactionID de la tabla y establezca un valor inicial adecuado.

20

5. Configure Pull Min TransactionID From Source de la manera siguiente.a. Edítela y establezca la Conexión para que sea el administrador de conexiones del

servidor de origen.b. Aunque puede almacenar su SQLStatement en una variable, en este ejemplo deje el

SQLSourceType como Entrada directa. Abra la ventana de entrada para SQLStatement y escriba la consulta siguiente: SELECT ISNULL(MIN(TransactionID), 0) FROM

Production.TransactionHistory

NOTA: pruebe las consultas SQL antes de introducirlas en los editores en SSIS. Esto simplifica la depuración, ya que no hay ayuda real de depuración en las ventanas del editor de consultas de SSIS.

Ilustración 5: configurar la tarea Ejecutar SQL para buscar el valor mínimo de transactionID en el origen.

c. Cierre la ventana Escribir consulta SQL haciendo clic en Aceptar. d. Establezca la propiedad ResultSet en Fila única.e. En el panel izquierdo del Editor de la tarea Ejecutar SQL, haga clic en Conjunto de

resultados para configurar cómo se va a capturar el valor de esta consulta.f. Haga clic en el botón Agregar para agregar un conjunto de resultados. g. En el nuevo conjunto de resultados, cambie el Nombre del resultado a 0. Asegúrese de

que User::minTransactionIDAtSource (la variable que creó en el paso 4) se muestra bajo Nombre de variable. Esta variable almacenará el resultado de la consulta SQL.

21

h. Cierre el Editor de la tarea Ejecutar SQL. No debe aparecer ningún error en la tarea después de cerrarla.

6. Arrastre otra tarea Ejecutar SQL hasta la superficie del flujo de control. Asigne a esta tarea el nombre Pull Max TransactionID from Destination. Conecte la restricción de precedencia de Correcto de Pull Min TransactionID From Source con esta nueva tarea.

7. Cree una nueva variable en el ámbito del paquete. Asigne a esta nueva variable el nombre maxTransactionIDAtDestination. Asígnele un tipo de datos de Int32 para que coincida con el tipo de datos de TransactionID y asígnele un valor inicial adecuado.

8. Abra el Editor de la tarea Ejecutar SQL para la nueva tarea y haga lo siguiente:a. Establezca ResultSet en Fila única.b. Establezca el administrador de conexiones del servidor de destinoc. SQLSourceType: Entrada directa d. En SQLStatement, use SELECT ISNULL(MAX(TransactionID), ?) FROM

Production.TransactionHistoryNOTA: ? es un parámetro de consulta. Estableceremos su valor en un momento.

e. Cierre el Editor de consultas haciendo clic en Aceptar y haga clic en Asignación de parámetros en el panel izquierdo del Editor de la tarea Ejecutar SQL.

f. Haga clic en Agregar para agregar un solo parámetro. i. En Nombre de variable, elija User::minTransactionIDAtSource.

ii. En Dirección, debe elegir Entrada. iii. El tipo de datos debe ser LONG, que es un entero de 32 bits en este contexto. iv. Cambie Nombre de parámetro a 0. Tenga en cuenta que esto debe cambiarse

a 0. El nombre en caracteres producirá un error.g. Haga clic en el Conjunto de resultados en el panel izquierdo. Haga clic en el botón

Agregar para agregar un nuevo conjunto de resultados. i. Cambie el Nombre del resultado a 0.

ii. En Nombre de variable, elija User::maxTransactionIDAtDestination, que es la variable que creó en el paso 7. Esta variable contendrá el resultado de la consulta que escriba cuando se ejecute esta tarea.

NOTA: el paso siguiente variará según el tipo de origen que use en el flujo de datos. Un origen de OLE DB puede usar una variable de SSIS que contenga una instrucción SQL como su consulta. Una conexión ADO.NET no puede hacerlo, pero se puede parametrizar para usar un parámetro de paquete o de proyecto como su consulta de origen. En este primer ejemplo, usará un origen de OLE DB con una variable que contiene la consulta de origen.

9. Arrastre una tarea Flujo de datos hasta su superficie de control. Cambie su nombre a Main data move y conecte la restricción de precedencia de Correcto de Pull Max TransactionID From Destination con esta tarea Flujo de datos.Cuando el paquete se ejecuta en este momento, ha almacenado los valores que necesita saber para establecer el punto inicial para la ejecución actual. A continuación, debe configurar una variable para almacenar la consulta de origen de SQL.

22

10. Cree una nueva variable cuyo ámbito sea el nivel de paquete. Asigne a esta variable el nombre sourceQuery y establezca su tipo de datos en cadena. Usará una expresión para derivar dinámicamente su valor en tiempo de ejecución según el valor que determinó como punto inicial para la consulta; para ello, haga lo siguiente.

a. Haga clic en el botón de puntos suspensivos situado a la derecha de la columna Expresión para abrir el Generador de expresiones.

b. Expanda el nodo Variables y parámetros en la ventana superior izquierda del Generador de expresiones. Usará la variable User::MaxTransactionIDAtDestination que creó en el paso 7. Debe ver esta variable en las variables enumeradas. Esta variable es de tipo Int32; sin embargo, la usará como parte de una variable de cadena. Para ello, necesitará convertirla a un tipo de datos DT_WSTR. En el panel superior derecho, expanda el nodo Conversiones de tipo para buscar la conversión de tipo (DT_WSTR, <<longitud>>).

c. En la expresión, escriba la consulta. En los lugares donde necesite su nombre de variable, o su conversión de tipo, puede arrastrarlos desde la ventana correspondiente hasta el cuadro Expresión para agregarlos. Esto ayuda a reducir el número de errores ortográficos en este editor. Genere la expresión de esta forma:

"SELECT TransactionID, ProductID, ReferenceOrderID, ReferenceOrderLineID, TransactionDate, TransactionType, Quantity, ActualCost, ModifiedDate FROM Production.TransactionHistory WHERE TransactionID > " + (DT_WSTR, 12 ) @[User::maxTransactionIDAtDestination] + " ORDER BY TransactionID"

Observe el uso de la conversión de tipo para cambiar el valor entero a una cadena con un máximo de 12 caracteres de ancho.

Se usó un ancho de 12 caracteres porque es suficientemente grande como para contener toda la gama de valores INT de SQL, incluido el negativo cuando proceda. En el caso de BIGINT, necesitará un ancho de 22 caracteres. Ajuste el tamaño de la variable en caracteres según el tipo de datos recuperado.

Cuando haya escrito la expresión, haga clic en el botón Evaluar expresión para asegurarse de que SSIS puede analizarla correctamente. Verá que ha colocado correctamente el valor inicial de maxTransactionIDAtDestination en la expresión evaluada. Este valor se establecerá correctamente en tiempo de ejecución.

Asegúrese de incluir la cláusula ORDER BY en la instrucción SQL. Solo con una cláusula ORDER BY obtiene un orden garantizado de una base de datos relacional. El método de reinicio que genere dependerá del orden de los valores de clave.

d. Cierre el Generador de expresiones haciendo clic en el botón Aceptar. La instrucción SQL generada dinámicamente se almacena ahora en la variable SourceQuery.

23

11. Haga doble clic en la tarea Flujo de datos Main data move para abrir la superficie de diseño de flujo de datos.

12. Arrastre un origen de OLE DB hasta la superficie de control de Flujo de datos. Cambie su nombre a Retrieve from TransactionHistory.

NOTA: no puede incluir un punto en el nombre de un componente de flujo de datos, por lo que el nombre completo Pull From Production.TransactionHistory no está permitido. Si no usa caracteres de subrayado para los nombres de tabla, puede sustituir el punto por el carácter de subrayado en la convención de nomenclatura de SSIS.

13. Haga doble clic en el origen Retrieve From TransactionHistory para abrir el Editor de origen de OLE DB.

a. En el Administrador de conexiones OLE DB, elija el administrador de conexiones Servidor de origen.

b. En la lista desplegable Modo de acceso a datos, elija Comando SQL de variable.c. En la lista desplegable Nombre de variable, elija la variable User::sourceQuery que creó

en el paso 10. d. Haga clic en Vista previa para asegurarse de que la consulta puede ejecutarse en el

servidor de origen.e. En la página Columnas del editor, asegúrese de que todas las columnas están seleccionadas.f. Haga clic en Aceptar para salir del Editor de origen de OLE DB.

14. Arrastre un destino de OLE DB hasta la superficie de control. Cambie su nombre a TransactionHistory Destination. Conecte el origen Retrieve From TransactionHistory con el nuevo destino. Abra el destino haciendo doble clic en él y configúrelo haciendo lo siguiente.

a. Elija el administrador de conexiones Servidor de destino en la lista desplegable Administrador de conexiones OLE DB.

b. En Modo de acceso a datos, elija Carga rápida de tabla o vista si no está ya seleccionado.c. En Nombre de la tabla o la vista, elija uno en el menú desplegable o escriba el nombre

del servidor de destino. En este caso, es Production.TransactionHistory.d. Si está usando la definición de TransactionHistory anterior, con fines de demostración,

puede conservar la configuración predeterminada en la página Administrador de conexiones. Si está usando la base de datos AdventureWorks, tendrá que seleccionar Mantener valores de identidad.

e. En la página Asignaciones del editor, asigne sus columnas.

NOTA: en casi todos los casos, es conveniente enviar las filas de error a un archivo de destino y redirigir la salida. No es necesario hacerlo para mostrar el reinicio en la canalización. Para conocer los pasos necesarios para crear un flujo de errores y redirigir filas, vea Configurar una salida de error en un componente de flujo de datos (http://msdn.microsoft.com/es-es/library/ms140083.aspx).

f. Haga clic en Aceptar para salir del Editor de destino de OLE DB.

24

15. Para probar este enfoque, inicie una importación y deténgala y, a continuación, reiníciela. Cada vez, el flujo de datos debe elegir la siguiente fila que es necesario mover. Se omiten las filas anteriores.

Acaba de generar un paquete simple que puede reiniciar su flujo de datos después de un error. Este paquete se usará como punto de partida para el ejemplo de diseño de un paquete que puede hacer reintentos. No desea que ninguna tarea del flujo de control guarde puntos de comprobación. Si se produce un error en el paquete y debe reiniciarse, necesita que se ejecuten los componentes Pull Min TransactionID From Source y Pull Max TransactionID From Destination para buscar exactamente dónde se interrumpió el flujo de datos en la ejecución anterior. El diseño de un paquete como este que puede encontrar su progreso y reiniciar su flujo es recomendable siempre que existan las características dentro de los datos para poder encontrar el punto en el que se interrumpió el flujo de datos. Sin embargo, esta práctica resulta especialmente importante en un entorno como la nube, que es más susceptible a las incertidumbres de la red.

Ejemplo con varios destinosEste principio puede extenderse a los flujos de datos con varios destinos. Este escenario es útil cuando se mueven datos a un modelo de datos particionado como suele ocurrir con Base de datos SQL de WA. En estos casos, se emplea una división condicional para enviar cada fila a su destino adecuado o bien, en datos de referencia, se puede usar una multidifusión para enviar todos los datos a todos los destinos. Estos son los principios clave que hay que recordar a la hora diseñar para el reinicio.

Los distintos destinos pueden haber progresado hasta puntos diferentes en el momento de producirse el error. Por tanto, debe buscar el valor de clave más alto insertado en cada destino. Cree una variable para almacenar el valor máximo de cada destino.

El punto inicial en el origen será el siguiente registro después del mayor valor de clave que se insertó correctamente en los destinos. Por ejemplo, si el mayor valor de clave insertado en un conjunto de particiones es el siguiente, en el origen debe reanudar el flujo de datos con el registro siguiente a 1000.

o Shard00 valor de clave 1000o Shard01 valor de clave 1100o Shard02 valor de clave 1050

Como esto deja abierta de la posibilidad de que algunos datos se extraigan más de una vez, debe filtrar por cada destino para evitar una infracción de clave principal. Use una transformación División condicional para filtrar los valores de clave que ya se han procesado.

En el ejemplo de particionamiento anterior, crearía variables denominadas maxTransactionIDAtShard00, maxTransactionIDAtShard01 y maxTransactionIDAtShard02. En las tareas Ejecutar SQL, encontraría los valores que hay que almacenar en cada una. En la división condicional, podría definir salidas con los nombres Shard00, Shard01 y Shard02. Las expresiones de las salidas son similares a las siguientes.

25

ShardID == 0 && TransactionID > @[User::maxTransactionIDAtShard00]ShardID == 1 && TransactionID > @[User::maxTransactionIDAtShard01]ShardID == 2 && TransactionID > @[User::maxTransactionIDAtShard02]

Si en la canalización entran algunas filas con valores menores que el TransactionID de una partición determinada, pero el registro va a esa partición, el registro no se enviará y no se producirá ninguna infracción de clave principal. Deje que estos registros vayan a la salida predeterminada o desconecte la salida para que no se procesen más.

Ilustración 2: una división condicional configurada para 3 particiones y para permitir el reinicio sin infracciones de clave principal en el destino. Al principio de cualquier ejecución, el valor de clave máximo en cada destino se almacena en las variables maxTransactionIDAtShardXX. En la canalización, esas filas destinadas a esa partición con un valor de clave demasiado bajo no se enviarán al destino y, por tanto, no se volverán a procesar. Estas filas irán a la salida predeterminada. Como la salida predeterminada no está conectada, no progresarán más en la canalización.

26

Otras sugerencias para el reinicio Cuando el destino sea un archivo, use una variable para representar el nombre de archivo

y hacer que todos los nombres de archivo sean significativos (por ejemplo, anexando un orden o una marca de tiempo al final). Procese los distintos fragmentos de datos en archivos diferentes. Si realiza el procesamiento en el mismo orden, y los fragmentos están definidos de forma determinista, puede ver qué archivos se han creado ya y determinar su punto de partida desde ahí. En función de sus necesidades y de la lógica, quizás necesite mover, cambiar el nombre o eliminar archivos que ya se han procesado.

Si el origen son varios archivos, procese cada archivo por separado y haga un seguimiento de cuál es el archivo actual. En el reinicio, puede reanudar después del último archivo que se procesó correctamente. Use una ordenación por nombre de archivo o por fecha para asegurarse de que siempre procesa los archivos en el mismo orden y poder determinar fácilmente el último archivo que se procesó correctamente.

Cuando el origen es SQL Server, puede usar un tipo de datos de cadena de SSIS para consultar valores enteros. Siempre y cuando la cadena se pueda convertir a un entero de SQL, SQL convertirá el tipo de datos durante la optimización. Mediante este principio, puede cambiar las variables MaxTransactionIDAtDestination y MinTransactionIDAtSource del paquete de ejemplo a una cadena, cambiar los tipos de parámetro de entrada de Pull Max TransactionID From Destination y usar este paquete como plantilla que también funcionará con claves principales de caracteres. No use un tipo de datos SQL_VARIANT con ningún otro tipo de datos de SQL, ya que esto producirá recorridos completos al recuperar los valores mínimo y máximo de clave.

Si el origen es un archivo, o cualquier origen que no pueda consultar con WHERE o cualquier otro tipo de cláusula de filtro, haga lo siguiente en el flujo de datos.

1. Coloque una transformación de división condicional entre los componentes de origen y de destino.

2. En la división condicional, configure una salida. Asigne a esta salida el nombre Papelera o cualquier otro nombre que le permita saber que no desea estas filas.

3. Para la condición que envía filas al destino, use una expresión para filtrar las filas que ya están en el destino. Por ejemplo, la expresión para el ejemplo anterior sería la siguiente.

[TransactionID] <= @[User::maxTransactionIDAtDestination]

4. No conecte la salida Papelera con ningún componente a menos que necesite realmente evaluar estas filas. Su único propósito es filtrar las filas que se procesaron en la última ejecución.

Esto no impide leer las filas que ya se han procesado de este archivo, pero evita que se envíen de nuevo a su destino, ahorrando así ancho de banda de red. Puesto que estas filas no se envían a un destino, no es necesario eliminar datos del destino.

27

Cuando se trate de claves compuestas, use subconsultas correlacionadas para buscar el punto de detención exacto. Asegúrese de ordenar los datos por las mismas claves. A continuación se muestra un ejemplo.

SELECT MAX(EmployeeID) AS EmployeeID, (SELECT MAX(EffectiveDate)

FROM HumanResources.EmployeeHistory i_forDate WHERE h.EmployeeID = i_forDate.EmployeeID) as EffectiveDate,

(SELECT MAX(EffectiveSequence) from HumanResources.EmployeeHistory i_forSeq where h.EmployeeID = i_forSeq.EmployeeID

and h.EffectiveDate = i.ForSeq.EffectiveDate) as EffectiveDateFROM HumanResources.EmployeeHistory hORDER BY EmployeeID, EffectiveDate, EffectiveSequence

Observe lo que hace el orden en el ejemplo. Si fuera a mover todos los registros de todos los empleados, y este fuera el orden de las claves, sería una buena forma de ordenación. Sin embargo, si todos los empleados (o algunos de ellos) ya existieran en el destino, y deseara importar únicamente los cambios que han surtido efecto desde la última importación, la ordenación por EffectiveDate, EffectiveSequence y EmployeeID sería la que necesitaría usar para poder reanudar desde donde se quedó. Analice lo que está importando para definir el orden que le permite determinar el punto en el que debe reanudar.

Diseñar para el reintento sin intervención manualLos componentes de origen y de destino de SSIS no incorporan directamente lógica de reintento. Sin embargo, el desarrollador de paquetes SSIS no está indefenso para abordar esta situación. Diseñar los paquetes SSIS de forma que pueda reiniciarlos sin perder el progreso en el flujo de datos también le permite reintentar automáticamente después de producirse un error teniendo en cuenta algunas consideraciones adicionales. En casos como el movimiento de datos hacia o desde Bases de datos SQL de WA, puede que necesite reintentar automáticamente para controlar las condiciones de error transitorias como la limitación de recursos o conexiones. Esta sección se basa en los conceptos mostrados en la sección anterior y presenta un ejemplo de lógica simple de reintento en el paquete. Después se muestra el uso de un enfoque fragmentado para permitir el reintento de cada fragmento con el fin de agregar solidez al paquete cuando sea más probable que se produzcan errores transitorios.

Para obtener más información acerca de la limitación de SQL, vea Guía de rendimiento y elasticidad de Base de datos SQL de Windows Azure (http://social.technet.microsoft.com/wiki/contents/articles/3507.windows-azure-sql-database-performance-and-elasticity-guide.aspx).

28

Incorporar reintentosEn los casos en que haya un único paquete, la incorporación de reintentos implica los pasos siguientes.

1. Determine el número máximo de veces que el paquete debe reintentarlo antes de generar un error. Para este ejemplo, determinaremos que se permitirá a un componente un máximo de 5 reintentos antes de que se produzca un error en el paquete. Cree una variable en el paquete denominada maxNumOfRetries. Asigne a esta variable el tipo int y el valor 5; se usará en expresiones en el paquete.

2. Configure una variable para almacenar el estado correcto. Cree una nueva variable en el paquete SSIS. Asigne a esta nueva variable el nombre attemptNumber.

3. Use un bucle FOR para reintentar hasta el número máximo de reintentos si el flujo de datos no es correcto.

29

4. Coloque la tarea Flujo de datos dentro del bucle FOR.5. Establezca la propiedad MaximumErrorCount del bucle FOR en el número máximo de veces que

se deber reintentar el flujo de datos para que un funcionamiento correcto después de un reintento no produzca un error en el paquete. Debe hacerlo con una expresión que use la variable maxNumOfRetries que configuró en el paso 1.

6. Use tareas Ejecutar SQL como se muestra en la sección anterior para buscar los valores mínimos de clave en el origen y los valores máximos de clave en el destino. En el caso de un intento simple, se puede hacer dentro del bucle FOR. Si se trata de ejemplos más avanzados, puede aparecer en cualquier otro lugar del flujo de control antes del bucle FOR.

7. Coloque las tareas Ejecutar SQL en el bucle FOR. 8. Conecte la restricción de Correcto de la tarea Ejecutar SQL con la tarea Flujo de datos.9. Conecte la restricción de precedencia de Correcto de la tarea Flujo de datos con una tarea Script

que establece la variable de estado de corrección en true para salir del bucle FOR. A continuación se muestra un ejemplo de la configuración de la tarea Script.

30

10. Conecte una restricción de precedencia de error de la tarea Flujo de datos con otra tarea Script durante un tiempo que espera que sea mayor que el problema esperado más frecuente o más molesto. Para este ejemplo usaremos 10 segundos para abarcar la posibilidad de limitación. Establezca el valor de la variable success en false.

31

11. Para cada tarea del bucle FOR, establezca la propiedad FailPackageOnFailure en false. En esta configuración, solo cuando se produzca un error en el bucle FOR después de usar todos los reintentos configurados se notificará un error y, por tanto, se producirá un error en el paquete.

12. Configure las tareas Ejecutar SQL después del error para que comprueben otra vez los valores mínimos de clave en el origen y los valores máximos de clave en el destino, de forma que se pueda reanudar el progreso sin realizar de nuevo ningún trabajo. Configure estas tareas como se describe en la subsección Diseñar para el reinicio de la sección Diseñar para el reinicio sin perder el progreso de la canalización anteriormente en este documento.

32

Cada vez que se produce un error en el flujo de datos, si no se ha alcanzado el número máximo de reintentos, el proceso vuelve al punto de encontrar el valor máximo de clave en el destino. El proceso continúa procesando desde el punto que se ha confirmado actualmente en el destino. Si hay varios destinos en el flujo de datos, empiece después de que el menor valor de clave haya llegado de forma segura al destino y use una división condicional o un flujo de error para controlar cualquier fila que pueda producir una infracción de clave principal.

Opciones de optimización del rendimiento de SSISAntes de comenzar a explicar las sugerencias y los trucos que rodean a la optimización del rendimiento de ETL, es necesario dar un paso atrás y examinar qué componentes y elementos móviles tiene. El proceso de ETL consta normalmente uno o varios de cada uno de los componentes siguientes:

Origen de datos: entrega datos Paquete que se ejecuta en el servidor SSIS: extrae datos del origen de datos, procesa

transformaciones si es necesario y carga datos en el destino

33

Destino: recibe datos. Un destino suele ser una base de datos con tablas que reciben los datos.

Todos estos elementos fundamentales funcionan conjuntamente a través de la interfaz de red y se pasan datos entre sí. Uno de los primeros pasos para optimizar el rendimiento de ETL consiste en asegurarse de que la red puede lograr el máximo rendimiento posible.

Para obtener más información acerca del servidor SSIS, vea Servidor de Integration Services (SSIS) (http://msdn.microsoft.com/es-es/library/gg471508.aspx).

Optimizar la configuración de redHay dos capas que pueden afectar a la forma en que se transmiten los datos entre los elementos definidos anteriormente: la configuración de la red física y la configuración de la conexión.

34

Configuración de redLa trama Ethernet define cuántos datos se pueden transmitir a través de la red de una vez. Se deben procesar todas las tramas, para lo cual se necesitan bastantes recursos de hardware y software. Si se aumenta el tamaño de trama (siempre y cuando lo admita el adaptador de red), se pueden enviar más bytes con una menor sobrecarga de CPU y aumentar el rendimiento reduciendo el número de tramas que hay que procesar.

Una trama Ethernet puede transportar hasta 9000 bytes. Esto se denomina una trama gigante. Para poder usar tramas gigantes, necesita cambiar la configuración de sus tarjetas de interfaz de red (NIC). Como se muestra en el ejemplo siguiente, la propiedad MaxJumboBuffers se establece en 8192 para permitir el uso de tramas gigantes.

Nota: al cambiar la configuración de la tarjeta de interfaz de red para usar tramas gigantes, asegúrese de que la infraestructura de red puede admitir este tipo de trama.SQL Server puede aceptar hasta 32676 bytes en un paquete de red de SSIS. Normalmente, si una aplicación tiene otro tamaño de paquete predeterminado diferente, este valor predeterminado reemplazará la configuración de SQL Server. Por tanto, se recomienda que establezca la propiedad Tamaño de paquete del administrador de conexiones de destino en el paquete SSIS al tamaño de paquete predeterminado de la aplicación.

Para editar esta propiedad, haga clic con el botón secundario en el administrador de conexiones en el Diseñador SSIS y, a continuación, haga clic en Editar. En el cuadro de diálogo Administrador de conexiones, haga clic en Todas.

35

Configuración del paquete SSISAdemás de la configuración de la cadena de conexión, hay otros valores que conviene ajustar para aumentar las capacidades de procesamiento de SQL Server.

El flujo de datos de SSIS reserva búferes de memoria para procesar datos. Cuando tiene servidores dedicados con varios núcleos y más memoria, normalmente se puede ajustar la configuración de memoria predeterminada para SSIS con el fin de aprovechar mejor las capacidades del servidor SSIS.

A continuación se indican las configuraciones de memoria de SSIS que conviene ajustar.

DefaultBufferSize DefaultBufferMaxRows EngineThreads

36

DefaultBufferSize y DefaultBufferMaxRows están relacionadas entre sí. El motor de flujo de datos intenta calcular el tamaño de una sola fila de datos. Este tamaño se multiplica por el valor almacenado en DefaultBufferMaxRows y el motor de flujo de datos intenta reservar el fragmento adecuado de memoria para el búfer.

[Valor del tamaño de búfer] = [Tamaño de una sola fila de datos] x [DefaultBufferMaxRows]

Si el valor del tamaño de búfer es mayor que el valor de DefaultBufferSize, el motor de flujo de datos reduce el número de filas de datos.

Si el valor de tamaño de búfer mínimo calculado internamente es mayor que el valor de tamaño de búfer, el motor de flujo de datos aumenta el número de filas de datos. Sin embargo, el motor no supera el valor de DefaultBufferMaxRows.

Cuando ajuste los valores de DefaultBufferSize y DefaultBufferMaxRows, se recomienda prestar atención a qué valores harán que el motor de flujo de datos escriba datos en los discos. La memoria paginada al disco del servidor SSIS afecta negativamente al rendimiento de la ejecución de paquetes SSIS. Puede observar el contador Búferes puestos en cola para determinar si se están escribiendo búferes de datos en el disco temporalmente cuando se ejecuta un paquete.

Para obtener más información sobre los contadores de rendimiento de los paquetes SSIS y cómo obtener estadísticas de contadores, vea Contadores de rendimiento (http://msdn.microsoft.com/es-es/library/ms137622.aspx).

La configuración EngineThreads sugiere al motor de flujo de datos cuántos subprocesos se pueden usar para ejecutar una tarea. Cuando se usa un servidor con varios núcleos, se recomienda que aumente el valor predeterminado de 10. Sin embargo, el motor no usará más subprocesos de los necesarios, cualquiera que sea el valor de esta propiedad. También puede suceder que el motor use más subprocesos que los especificados en esta propiedad si es necesario para evitar problemas de simultaneidad. Un buen punto de partida para los paquetes complejos es usar un mínimo de 1 subproceso de motor por árbol de ejecución mientras no sea menor que el valor predeterminado de 10.

37

Para obtener más información sobre estos valores, vea Características de rendimiento del flujo de datos (http://msdn.microsoft.com/es-es/library/ms141031.aspx).

Consideraciones especiales sobre los datos BLOBCuando en una canalización de SSIS haya más datos de los que caben en el búfer de canalización con un tamaño preestablecido, los datos se podrán en cola. Esto constituye un problema de rendimiento, especialmente cuando se trabaja con datos BLOB como datos XML, de texto o de imagen. Cuando hay datos BLOB en la canalización, SSIS reserva la mitad de un búfer para los datos consecutivos y la otra mitad para los datos BLOB. Los datos BLOB que no quepan en la mitad del búfer se pondrán en cola. Por tanto, debe realizar las acciones siguientes para optimizar los paquetes SSIS cuando vaya a haber datos BLOB en la canalización:

1. Cambie el valor de BLOBTempStoragePath y BufferTempStoragePath para apuntar a una unidad de alto rendimiento. De forma predeterminada, los objetos puestos en cola se escribirán en archivos temporales en el directorio definido por las variables de entorno TEMP o TMP. De forma predeterminada, este directorio se encuentra en la unidad del sistema operativo. Normalmente, la unidad del sistema operativo no es una unidad de alto rendimiento. Puede asegurarse de que los archivos de datos temporales puestos en cola se escriben en una unidad de alto rendimiento si cambia el valor de BLOBTempStoragePath en las propiedades de la tarea Flujo de datos de SSIS para que apunte a un directorio de almacenamiento de alto rendimiento. Como ocurre con todas las propiedades en SSIS, puede usar expresiones para establecer este valor.

2. Ajuste el tamaño de DefaultBufferSize y DefaultBufferMaxRows para minimizar las puestas en cola. Puesto que los discos suelen ser el componente más lento del servidor, y su velocidad suele ser mucho menor que la del procesador o la memoria, puede pensar que un uso ineficiente del espacio en búfer es más eficiente que permitir la puesta en cola. Para minimizar la puesta en cola debido a datos BLOB, use un método como el siguiente para determinar los valores de DefaultBufferSize y DefaultBufferMaxRows cuando tenga datos BLOB en el flujo de datos.

a. Determine el valor de MaxBufferSize. Puesto que tendrá datos BLOB en el flujo de datos, un buen punto de partida puede ser el valor máximo permitido, que es 100 MB o 104857600 bytes.

b. Divida este número entre 2. En el ejemplo, esto da 52428800 bytes. Esta es la mitad del búfer que puede contener datos BLOB.

c. Seleccione un tamaño que usará para el tamaño estimado de los datos BLOB que procesará en este flujo de datos. Un buen punto de partida para este tamaño es la longitud promedio + 2 desviaciones estándar de la longitud promedio de todos los datos blob que habrá en un búfer. Este valor contendrá aproximadamente el 98 % de todos los datos blob. Como es probable que haya más de una fila en un único búfer de SSIS, esto asegurará que prácticamente no se realice ninguna puesta en cola.

38

Si el origen es SQL Server, puede usar una consulta como la siguiente para adquirir la longitud:

SELECT CAST(

AVG(DATALENGTH(ColName)) + (2 * STDEV(DATALENGTH(Demographics))) AS INT

) AS Length FROM SchemaName.TableName

Si la tabla es demasiado grande para permitir la consulta de todo el conjunto de datos y obtener el promedio y la desviación estándar, use un método como el que se describe en Muestreo aleatorio en T-SQL (http://msdn.microsoft.com/es-es/library/aa175776(v=SQL.80).aspx) para ver un ejemplo de cómo averiguar la longitud que se debe usar.

d. Divida el número que obtuvo en el paso b entre el número que obtuvo en el paso c. Use este número o un número ligeramente menor como valor de DefaultBufferMaxRows para la tarea Flujo de datos.

SUGERENCIA: los valores de DefaultBufferMaxRows y MaxBufferSize se pueden configurar mediante expresiones. Puede beneficiarse de esta opción para los conjuntos de datos en los que la naturaleza estadística de la longitud de datos blob puede cambiar a menudo o para la creación de paquetes plantilla para establecer estos valores en tiempo de ejecución. Para que sean dinámicos, haga lo siguiente.

1. Cree una nueva variable en el nivel de paquete. Asigne a la nueva variable el nombre DefaultMaxRowsInBuffer. Conserve el tipo de datos Int32. Puede crear una variable similar si desea establecer la propiedad MaxBufferSize dinámicamente.

2. Use una tarea Ejecutar SQL o una tarea Script para encontrar el valor que usará para DefaultBufferMaxRows. Almacene el valor calculado en la variable DefaultMaxRowsInBuffer que creó en el paso 1.

NOTA: para obtener más información sobre cómo usar una tarea Ejecutar SQL para recuperar un único valor en una variable de SSIS, vea Conjuntos de resultados en la tarea Ejecutar SQL (http://technet.microsoft.com/es-es/library/cc280492.aspx).

3. En el cuadro de propiedades de la tarea Flujo de datos donde desea establecer DefaultBufferMaxRows, seleccione Expresiones para abrir el cuadro de diálogo Editor de expresiones de propiedad.

4. En el Editor de expresiones de propiedad, elija DefaultBufferMaxRows en el menú desplegable Propiedad y haga clic en el botón de puntos suspensivos para abrir el Generador de expresiones.

5. Arrastre la variable que creó en el paso 1 desde la lista Variables y parámetros de la esquina superior izquierda hasta el cuadro Expresión y haga clic en Evaluar expresión para ver el valor predeterminado de la variable en el cuadro Valor evaluado.

39

6. Haga clic en Aceptar en los cuadros de diálogo Generador de expresiones y Editor de expresiones de propiedad para guardar la configuración. En esta configuración, el valor de las propiedades se establecerá en tiempo de ejecución para reducir al mínimo las posibilidades de transferir datos BLOB a discos.

Usar características nuevas de SSIS 2012 para supervisar el rendimiento en un sistema distribuidoSQL Server 2012 cuenta con características nuevas para supervisar el rendimiento de los proyectos de Integration Services (SSIS) que se implementan en el servidor SSIS. Puede registrar información de rendimiento en tiempo de ejecución sobre la ejecución de un paquete, ver estadísticas de ejecución de un paquete y supervisar el flujo de datos de un paquete.

Registrar estadísticas de rendimientoPara especificar el ámbito de la información que se registra durante la ejecución de paquetes, seleccione uno de los niveles de registro siguientes. Para registrar estadísticas de rendimiento, seleccione los niveles de registro de rendimiento o detallado.

40

Nivel de registro Valor DescripciónNinguno 0 El registro está desactivado. Solo se registra el estado de ejecución

del paquete.Básico 1 Se registran todos los eventos, excepto los eventos personalizados y de

diagnóstico. Es el valor predeterminado.Rendimiento 2 Solo se registran las estadísticas de rendimiento, y los eventos OnError

y OnWarning.Detallado 3 Se registran todos los eventos, incluidos los eventos personalizados y de

diagnóstico.

Integration Services proporciona un amplio conjunto de eventos personalizados para escribir entradas del registro de paquetes y muchas tareas. Puede usar estas entradas para guardar información detallada sobre el progreso, los resultados y los problemas de ejecución si registra eventos predefinidos o mensajes definidos por el usuario para su análisis posterior.

Para obtener más información, vea Mensajes personalizados para registro (http://msdn.microsoft.com/es-es/library/ms345174.aspx)

A continuación se indican varias formas de especificar el nivel de registro para una instancia de una ejecución de paquetes.

Establezca los parámetros de una instancia de ejecución de paquetes mediante el procedimiento almacenado catalog.set_execution_parameter_value (http://msdn.microsoft.com/es-es/library/ff877990.aspx).

Configure una instancia de una ejecución de paquetes mediante el cuadro de diálogo Ejecutar paquete.

Configure un trabajo del Agente SQL Server para una ejecución de paquetes mediante el cuadro de diálogo Nuevo paso de trabajo.

Para establecer el nivel de registro mediante el cuadro de diálogo Ejecutar paquete

1. En SQL Server Management Studio, navegue hasta el paquete en el Explorador de objetos.2. Haga clic con el botón secundario en el paquete y seleccione Ejecutar.3. Seleccione la pestaña Avanzadas.4. En Nivel de registro, seleccione el nivel de registro.

41

Para establecer el nivel de registro mediante el cuadro de diálogo Nuevo paso de trabajo

1. Cree un nuevo trabajo; para ello, expanda el nodo Agente SQL Server en el Explorador de objetos, haga clic con el botón secundario en Trabajos y, a continuación, haga clic en Nuevo trabajo.

O bien

Modifique un trabajo existente; para ello, expanda el nodo Agente SQL Server, haga clic con el botón secundario en un trabajo existente y, a continuación, haga clic en Propiedades.

2. Haga clic en Pasos en el panel izquierdo y, a continuación, haga clic en Nuevo para abrir el cuadro de diálogo Nuevo paso de trabajo.

3. Seleccione Paquete SQL Server Integration Services en el cuadro de lista Tipo.4. En la pestaña Paquete, seleccione Catálogo de SSIS en el cuadro de lista Origen del paquete,

especifique el servidor y, después, especifique la ruta de acceso del paquete en el cuadro Paquete.

5. En la pestaña Configuración, haga clic en Avanzadas y seleccione un nivel de registro en el cuadro de lista Nivel de registro.

6. Termine de configurar el paso de trabajo y guarde los cambios.

Para establecer el nivel de registro mediante el procedimiento almacenado catalog.set_execution_parameter_value, establezca parameter_name en LOGGING_LEVEL y parameter_value en el valor correspondiente al nivel de rendimiento o detallado. En el ejemplo siguiente se crea una instancia de una ejecución para el paquete Paquete.dtsx y se establece el nivel de registro en 2. El paquete se encuentra en el proyecto PaquetesSSIS y el proyecto está en la carpeta Paquetes.

Declare @execution_id bigint

exec catalog.create_execution 'Paquetes', 'PaquetesSSIS', 'Paquete.dtsx', NULL, 1, @execution_id outputexec catalog.set_execution_parameter_value @execution_id, 50, 'LOGGING_LEVEL', 2

Ver estadísticas de ejecuciónLas vistas de base de datos y los procedimientos almacenados de SSISDB, y los informes estándar disponibles en SQL Server Management Studio, proporcionan una gran cantidad de información sobre las ejecuciones de paquetes e información que es pertinente para las ejecuciones. Una ejecución es una instancia de ejecución de paquete.

De los informes estándar, los informes Panel de Integration Services, Todas las ejecuciones y Todas las conexiones son especialmente útiles para ver información sobre la ejecución de paquetes.

El informe Panel de Integration Services proporciona la siguiente información sobre los paquetes que se están ejecutando o que han terminado de ejecutarse en las últimas 24 horas.

42

Informe Panel de Integration Services

Sección del informe DescripciónInformación de ejecución

Muestra el número de ejecuciones que están en distintos estados (error, en ejecución, correcto, otros).

Información de paquete

Muestra el número total de paquetes que se han ejecutado.

Información de conexión

Muestra las conexiones que se han usado en las ejecuciones con error.

Información detallada del paquete

Para cada paquete, muestra los detalles de las ejecuciones completadas. Por ejemplo, verá el número de ejecuciones con errores frente al número total de ejecuciones, la duración de las ejecuciones (en segundos) y la duración promedio de las ejecuciones durante los últimos tres meses.

Puede ver información de ejecución adicional sobre un paquete si hace clic en Rendimiento de la ejecución, Información general y Todos los mensajes.

El informe Rendimiento de la ejecución muestra la duración de las últimas 10 ejecuciones correctas, y el Tiempo activo y el Tiempo total para los componentes de flujo de datos del paquete. El tiempo activo se refiere a la cantidad de tiempo total que la durado la ejecución del componente en todas las fases y el tiempo total se refiere al tiempo total transcurrido para un componente. El informe muestra esta información para los componentes de flujo de datos solo cuando el nivel de registro de la última ejecución del paquete se estableció en Performance (Rendimiento) o Verbose (Detallado).

El informe Información general muestra el estado de las tareas del paquete. El informe Mensajes muestra los mensajes de eventos y los mensajes de error para el paquete y las tareas, como las horas de inicio y de finalización, y el número de filas escritas.

43

El informe Todas las ejecuciones proporciona la siguiente información para las ejecuciones que se han realizado en la instancia conectada de SQL Server. Puede haber varias ejecuciones del mismo paquete. A diferencia del informe Panel de Integration Services, puede configurar el informe Todas las ejecuciones para que muestre las ejecuciones que se han iniciado durante un intervalo de fechas. Las fechas pueden abarcar varios días, meses o años.

Informe Todas las ejecuciones

Sección del informe DescripciónFiltro Muestra el filtro actual que se aplica al informe,

como el Intervalo de tiempo de inicio.Información de ejecución Muestra la hora de inicio, la hora de finalización

y la duración de cada ejecución de paquete.

Puede ver una lista de los valores de parámetros usados con una ejecución de paquetes, como los valores que se pasaron a un paquete secundario mediante la tarea Ejecutar paquete. Para ver la lista de parámetros, haga clic en Información general.

44

El informe Todas las conexiones proporciona la siguiente información para las conexiones con errores, para las ejecuciones que se ha realizado en la instancia de SQL Server.

Sección del informe DescripciónFiltro Muestra el filtro actual que se aplica al informe,

como conexiones con una cadena especificada y el intervalo de Hora del último error.

Establezca el intervalo de Hora del último error para que se muestren solo los errores de conexión que se produjeron durante un intervalo de fechas. El intervalo puede abarcar varios días, meses o años.

Detalles Muestra la cadena de conexión, el número de ejecuciones en las que se produjo un error de conexión y la fecha en la que hubo un error de conexión por última vez.

45

Además de ver los informes estándar disponibles en SQL Server Management Studio, también puede consultar las vistas de base de datos de SSISDB para obtener información similar sobre las ejecuciones de paquetes. En la tabla siguiente se describen las vistas principales.

Vista de base de datos de SSISDB Descripcióncatalog.executable_statistics(http://msdn.microsoft.com/es-es/library/hh479592.aspx)

Muestra una fila para cada ejecutable que se ejecuta, incluida cada iteración de un ejecutable. Un ejecutable es una tarea o un contenedor que se agrega al flujo de control de un paquete.

Por ejemplo, la vista muestra la cantidad de tiempo que duró la ejecución del ejecutable, las horas a las que el ejecutable entra en las fases previa a la ejecución y posterior a la ejecución, y el resultado de ejecución del ejecutable, como correcto o con errores.

Un ejemplo de un resultado de ejecución es el código de retorno de un procedimiento almacenado ejecutado por una tarea Ejecutar SQL. Para obtener más información, vea Parámetros y códigos de retorno en la tarea Ejecutar SQL.

catalog.executions(http://msdn.microsoft.com/es-es/library/ff878089.aspx)

Muestra información sobre las ejecuciones de paquetes. Los paquetes que se ejecutan con la tarea Ejecutar paquete se ejecutan en la misma instancia que el paquete primario.

Por ejemplo, la vista muestra el estado de una ejecución (en ejecución, con errores, correcto, etc.), la memoria física total y la memoria física disponible en el servidor cuando se inicia la ejecución, y la memoria de página total y la memoria de página disponible cuando se inicia la ejecución.

catalog.execution_component_phases(http://msdn.microsoft.com/es-es/library/hh230981.aspx)

Muestra las horas de inicio y de finalización de los componentes de flujo de datos, para cada fase de una ejecución. Esta información se muestra para varias ejecuciones de paquetes.

La vista muestra esta información para los componentes de flujo de datos solo cuando el nivel de registro de la ejecución se ha establecido en Rendimiento o en Detallado.

catalog.event_messages(http://msdn.microsoft.com/es-es/library/hh479594.aspx)

Muestra información sobre los mensajes que se registraron durante operaciones como la creación y el inicio de una ejecución de paquete. El valor de este tipo de operación es 200.

Por ejemplo, la vista muestra el texto del mensaje, el componente del paquete y el componente de flujo de datos que son el origen del mensaje, y el evento asociado al mensaje.Los mensajes que muestra la vista para una ejecución de paquete dependen de la configuración del nivel de registro de la ejecución.

46

Vista de base de datos de SSISDB Descripcióncatalog.event_message_context(http://msdn.microsoft.com/es-es/library/hh479590.aspx)

Muestra información sobre las condiciones asociadas a los mensajes de eventos de ejecución.

Por ejemplo, la vista muestra el objeto asociado al mensaje de evento como un valor de variable o una tarea, y el nombre y el valor de propiedad asociados al mensaje de evento.

La vista también muestra el identificador de cada mensaje de evento. Puede buscar información adicional sobre un mensaje de evento específico si consulta la vista catalog.event_messages.

Puede usar la vista catalog.execution_component_phases para calcular el tiempo empleado en la ejecución en todas las fases (tiempo activo) y el tiempo total transcurrido (tiempo total) para los componentes del paquete. Esto puede ayudar a identificar los componentes que se pueden estar ejecutando más despacio de lo esperado.

Esta vista se rellena cuando el nivel de registro de la ejecución de paquete se estableció en Performance (Rendimiento) o Verbose (Detallado). Para obtener más información, vea Registrar estadísticas de rendimiento en este artículo.

En el ejemplo siguiente, se calculan el tiempo activo y el tiempo total para los componentes de la ejecución cuyo identificador es 33. En el cálculo se emplean las funciones SUM y DATEDIFF.

Declare @execution_id bigint

Set @execution_id = 33

select package_name, task_name, subcomponent_name, execution_path,

sum (DATEDIFF(ms, start_time, end_time)) as active_time,

DATEDIFF(ms,min(start_time), max(end_time)) as total_time

from catalog.execution_component_phases

where execution_id = @execution_id

group by package_name, task_name, subcomponent_name, execution_path

order by active_time desc

47

Por último, puede usar la función dm_execution_performance_counters funciona para obtener estadísticas de contadores de rendimiento, como el número de búferes usados, y el número de filas leídas y escritas para una ejecución actual.

En el ejemplo siguiente, la función devuelve estadísticas para la ejecución actual que tiene el identificador 34.

select * from [catalog].[dm_execution_performance_counters] (34)

En el ejemplo siguiente, la función devuelve estadísticas para todas las ejecuciones actuales.

select * from [catalog].[dm_execution_performance_counters] (NULL)

Supervisar el flujo de datosIntegration Services incluye características y herramientas que puede usar para solucionar problemas del flujo de datos en un paquete durante su ejecución.

Derivar el flujo de datos durante la ejecuciónSQL Server Integration Services (SSIS) en SQL Server 2012 incluye una característica nueva que permite agregar una derivación de datos en una ruta de flujo de datos de un paquete en tiempo de ejecución y dirigir el resultado de la derivación de datos a un archivo externo. Para usar esta característica, debe implementar el proyecto de SSIS con el modelo de implementación de proyectos en un servidor de SSIS. Después de implementar el paquete en el servidor, debe ejecutar scripts T-SQL en la base de datos de SSISDB para agregar derivaciones de datos antes de ejecutar el paquete. A continuación se muestra un escenario de ejemplo:

48

1. Cree una instancia de ejecución de un paquete mediante el procedimiento almacenado catalog.create_execution (http://msdn.microsoft.com/es-es/library/ff878034.aspx).

2. Agregue una derivación de datos mediante el procedimiento almacenado catalog.add_data_tap (http://msdn.microsoft.com/es-es/library/hh230989) o catalog.add_data_tap_by_guid (http://msdn.microsoft.com/es-es/library/hh230991).

3. Inicie la instancia de ejecución del paquete mediante el procedimiento almacenado catalog.start_execution (http://msdn.microsoft.com/es-es/library/ff878160).

A continuación se muestra un script SQL de ejemplo que realiza los pasos descritos en el escenario anterior:

Declare @execid bigintEXEC [SSISDB].[catalog].[create_execution] @folder_name=N'ETL Folder', @project_name=N'ETL Project', @package_name=N'Package.dtsx', @execution_id=@execid OUTPUTEXEC [SSISDB].[catalog].add_data_tap @execution_id = @execid, @task_package_path = '\Package\Data Flow Task', @dataflow_path_id_string = 'Paths[Flat File Source.Flat File Source Output]', @data_filename = 'output.txt'EXEC [SSISDB].[catalog].[start_execution] @execid

Los parámetros de nombre de carpeta, nombre de proyecto y nombre de paquete del procedimiento almacenado create_execution corresponden a los nombres de carpeta, proyecto y paquete del catálogo de Integration Services. Puede obtener los nombres de carpeta, proyecto y paquete que se van a usar en la llamada a create_execution desde SQL Server Management Studio como se muestra en la ilustración siguiente. Si no aparece su proyecto de SSIS aquí, puede que no haya implementado el proyecto en el servidor de SSIS todavía. Haga clic con el botón secundario en el proyecto de SSIS en Visual Studio y, a continuación, haga clic en Implementar para implementar el proyecto en el servidor de SSIS esperado.

49

En lugar de escribir las instrucciones SQL, puede generar el script de ejecución del paquete siguiendo estos pasos:

1. Haga clic con el botón secundario en Package.dtsx y, a continuación, haga clic en Ejecutar. 2. Haga clic en el botón Script de la barra de herramientas para generar el script.3. Ahora, agregue la instrucción add_data_tap antes de la llamada a start_execution.

El parámetro task_package_path del procedimiento almacenado add_data_tap corresponde a la propiedad PackagePath de la tarea Flujo de datos en Visual Studio. En Visual Studio, haga clic con el botón secundario en la tarea Flujo de datos y, a continuación, haga clic en Propiedades para abrir la ventana Propiedades. Anote el valor de la propiedad PackagePath para usarlo como valor del parámetro task_package_path en la llamada al procedimiento almacenado add_data_tap.

El parámetro dataflow_path_id_string del procedimiento almacenado add_data_tap corresponde a la propiedad IdentificationString de la ruta de flujo de datos a la que desea agregar una derivación de datos. Para obtener el parámetro dataflow_path_id_string, haga clic en la ruta de flujo de datos y anote el valor de la propiedad IdentificationString de la ventana Propiedades.

50

Cuando se ejecuta el script, el archivo de salida se almacena en la carpeta <Archivos de programa>\Microsoft SQL Server\110\DTS\DataDumps. Si ya existe un archivo con ese nombre, se creará un nuevo archivo con un sufijo (por ejemplo: output[1].txt).

Como se ha mencionado anteriormente, también puede usar el procedimiento almacenado catalog.add_data_tap_by_guid (http://msdn.microsoft.com/es-es/library/hh230991) en lugar del procedimiento almacenado add_data_tap. Este procedimiento almacenado toma el identificador de la tarea Flujo de datos como parámetro en lugar de task_package_path. Puede obtener el identificador de la tarea Flujo de datos de la ventana Propiedades en Visual Studio.

Quitar una derivación de datosPuede quitar una derivación de datos antes de iniciar la ejecución mediante el procedimiento almacenado catalog.remove_add_data_tap. Este procedimiento almacenado toma el identificador de la derivación de datos como parámetro, que puede obtener como resultado del procedimiento almacenado add_data_tap.

DECLARE @tap_id bigint

EXEC [SSISDB].[catalog].add_data_tap @execution_id = @execid, @task_package_path = '\Package\Data Flow Task', @dataflow_path_id_string = 'Paths[Flat File Source.Flat File Source Output]', @data_filename = 'output.txt' @data_tap_id=@tap_id OUTPUT

EXEC [SSISDB].[catalog].remove_data_tap @tap_id

51

Enumerar todas las derivaciones de datosTambién puede enumerar todas las derivaciones de datos mediante la vista catalog.execution_data_taps. En el ejemplo siguiente se extraen las derivaciones de datos para una instancia de ejecución especificada (Id.: 54).

select * from [SSISDB].[catalog].execution_data_taps where execution_id=@execid

Consideración sobre el rendimientoAl habilitar el nivel de registro detallado y agregar derivaciones de datos aumentan las operaciones de E/S que realiza la solución de integración de datos. Por tanto, se recomienda agregar derivaciones de datos solo para solucionar problemas.

Supervisar el flujo de datos durante la ejecuciónPuede usar la vista de base de datos de SSISDB catalog.execution_data_statistics (http://msdn.microsoft.com/es-es/library/hh230986.aspx) para analizar el flujo de datos de paquetes. Esta vista muestra una fila cada vez que un componente de flujo de datos envía datos a un componente de nivel inferior. La información se puede usar para entender mejor las filas que se envían a cada componente.

Nota: el nivel de registro se debe establecer en Verbose (detallado) para capturar información con la vista catalog.execution_data_statistics.

En el ejemplo siguiente se muestra el número de filas enviadas entre los componentes de un paquete. execution_id es el identificador de una instancia de ejecución que puede obtener como valor de retorno del procedimiento almacenado create_execution o de la vista catalog.executions.

use SSISDBselect package_name, task_name, source_component_name, destination_component_name, rows_sentfrom catalog.execution_data_statisticswhere execution_id = 132order by source_component_name, destination_component_name

52

En el ejemplo siguiente se calcula el número de filas enviadas por milisegundo por cada componente de una ejecución concreta. Los valores calculados son:

total_rows: la suma de todas las filas enviadas por el componente wall_clock_time_ms: el tiempo de ejecución total transcurrido, en milisegundos, para cada

componente num_rows_per_millisecond: el número de filas por milisegundo enviadas por cada componente

La cláusula HAVING se usa para evitar un error de división por cero en los cálculos.

use SSISDBselect source_component_name, destination_component_name, sum(rows_sent) as total_rows, DATEDIFF(ms,min(created_time),max(created_time)) as wall_clock_time_ms, ((0.0+sum(rows_sent)) / (datediff(ms,min(created_time),max(created_time)))) as [num_rows_per_millisecond]from [catalog].[execution_data_statistics]where execution_id = 132group by source_component_name, destination_component_namehaving (datediff(ms,min(created_time),max(created_time))) > 0order by source_component_name desc

ConclusiónSQL Server Integration Services (SSIS) se puede usar como herramienta para mover datos hacia y desde Base de datos SQL de Windows Azure (WA) como parte de la solución total de extracción, transformación y carga (ETL) y como parte de la solución de movimiento de datos. SSIS se puede usar para mover datos entre orígenes y destinos en la nube, y en un escenario híbrido entre la nube y una instancia local. En este documento se han descrito las prácticas recomendadas de SSIS para los orígenes y los destinos en la nube, se ha descrito la planeación de proyectos de SSIS tanto si el proyecto está completamente en la nube como si implica movimientos de datos híbridos, y se ha recorrido un ejemplo de cómo maximizar el rendimiento en un movimiento híbrido escalando horizontalmente el movimiento de datos.

53

Para obtener más información:

http://www.microsoft.com/sqlserver/: Sitio web de SQL Server

http://technet.microsoft.com/es-es/sqlserver/: SQL Server TechCenter

http://msdn.microsoft.com/es-es/sqlserver/: Centro para desarrolladores de SQL Server

¿Le sirvió de ayuda este documento? Proporciónenos su opinión. Díganos, en una escala de 1 (poco útil) a 5 (excelente), cómo calificaría este documento y por qué lo valora con esta puntuación. Por ejemplo:

¿Lo valora alto debido a que tiene buenos ejemplos, capturas de pantalla excelentes, una redacción comprensible u otra razón?

¿Lo valora bajo debido a que sus ejemplos son escasos, las capturas de pantalla son borrosas o su redacción es poco clara?

Esta información nos ayudará a mejorar la calidad de las notas del producto que publicamos.

Enviar comentarios.

54