Optimización de SQL Server 2005 Integration Services para la conversión de datos EBCDIC

Al buscar en la Web de soluciones para el uso de SQL Server 2005 Integration Services para convertir y cargar EBCDIC (IBM mainframe) de datos, muchos se alcanzó un puesto de control masivo. A través de exhaustivas búsquedas que puede ser capaz de devolver una cantidad mínima de información, ninguna de las cuales es probable que se refieren a la optimización del rendimiento una vez a la solución de conversión está en su lugar.
Recientemente, fue llamado a convertir un archivo de un cliente externo que contenía 5 millones de discos a 497 bytes por registro. Lamentablemente, el "fuera de la caja" la versión de Microsoft SQL Server 2005 Business Intelligence Development Studio (BIDS) no es compatible con una rutina de conversión para transformar correctamente entre dos páginas de códigos diferentes, por ejemplo EBCDIC (37) y ASCII (1252). Después de algunos persistentes buscando fui capaz de encontrar una muestra de componentes personalizados en el sitio web de Microsoft llamada "CodePageConvert" [1]. Una vez que esto msi está correctamente compilado y se agrega al menú de las transformaciones de flujo de datos, usted debería ser capaz de transformar los datos entre dos páginas de códigos.
Para darle un poco de historia, la máquina que se está ejecutando actualmente este proceso se está ejecutando Windows Server 2003 con SP2 y un Dual Xeon 2.66 GHz Intel X5355 con memoria de 3840. El paquete llama a un servidor de archivos externos para el archivo de datos en bruto y escribe datos en una conexión OLE DB (base de datos de SQL Server) que ejecuta Microsoft SQL Server 2000 en otro servidor de archivos externos.
Lo ideal sería que yo quería ser capaz de procesar estos datos de manera más eficiente con menos tensión en el hardware, el tiempo de ejecución y el tamaño de la tabla. Sin el ajuste de rendimiento en su lugar el proceso toma aproximadamente 9 minutos para completar la conversión de datos completa. El archivo RAW es cerca de 2,5 GB y el tamaño de la tabla resultante es 3.3GB. Yo sabía que tenía que ser factible de hacerlo mejor que eso, y si es posible que yo quería para reducir de manera significativa tanto el tiempo de ejecución y el tamaño de la tabla.
Procedimientos de empleo:

Vi que sólo necesitaba sólo algunos de los campos que han sido enviados desde el cliente externo. Después de un análisis exhaustivo de las necesidades de nuestros datos, que decidió retirar 10 columnas del paquete con un ahorro total de 254 bytes por registro. Esto nos deja con un total de 243 bytes por registro utilizable (497 [inicial] - 254 [excluidos] = 243 [útil]). Obviamente, esta modificación representa una reducción significativa en el tiempo de proceso y la huella de la base de datos. El aumento de la inserción cometer tamaño - Permite al usuario establecer un tampón específica cometer tamaño para la carga en SQL Server. Esta configuración está disponible en el Editor de destino de OLE DB cuando se utiliza el controlador de SQL Server OLE DB. De forma predeterminada, SSIS especifica un compromiso tamaño de 0, lo que significa que SSIS intentará cargar todas las filas en un único lote que tiene un efecto negativo para los archivos especialmente grandes. Al aumentar el tamaño de insertar comprometerse a decir ... ... 1 millón de registros, que divide los datos hasta en 5 pequeños compromete a que no ejerza presión sobre el procesador como mucho. Buffer Tuning - El aumento de la DefaultMaxBufferRows para la tarea Flujo de datos permite al usuario reducir el número de búferes de movimiento a través del flujo de datos.

SSIS multiplica el tamaño de fila estimado (en mi caso sería 243 bytes) por el DefaultMaxBufferRows para medir el tamaño del conjunto de datos por cada 10.000 registros. El DefaultMaxBufferRows no debe aumentarse demasiado significativa, porque esto hará que el motor de ejecución que cambiar amortiguadores en el disco, por lo que derrotar al efecto, todos juntos.

Los datos brutos ubicación - Traslado de los datos del cliente prima hasta el servidor que aloja SSIS debe mejorar el tiempo de acceso a datos en general. Ahora SSIS no tendrá que llegar a través de la red para tomar los datos del archivo RAW. También esto disminuye la probabilidad de error, como problemas de conexión de red.

Ubicación del servidor SQL - Mover el servidor SQL de destino para el mismo servidor de hosting SSIS mejora el tiempo de escritura de SQL Server, también disminuye la probabilidad de error.

OLE DB para SQL Server de destino - Para aquellos de ustedes ya se está ejecutando un 2005 pleno derecho de almacenamiento de datos, que probablemente ya estén utilizando las ventajas de rendimiento de un servidor de destino de SQL Server 2005. A diferencia de la solución existente, que estaba escribiendo a un SQL Server 2000, con el destino de SQL Server mejorará significativamente el tiempo de escritura de datos a través de SSIS en el servidor SQL.

Resultados:
ganancias importantes de los resultados se lograron mediante la aplicación de los procedimientos anteriores. Las mayores mejoras demostró ser excluidos los datos innecesarios y cambiar el destino de OLE DB a un destino de SQL Server para SQL Server 2005. Como dije antes, el actual proceso tuvo un total de casi 9 minutos para iniciar, ejecutar y carga de 5 millones de registros a SQL Server. Después de la aplicación de la exclusión de datos, ajuste de amortiguación, colocando los datos en bruto en el servidor de aplicaciones, la carga de datos al servidor de aplicaciones y cambiar el destino de OLE DB a un destino de SQL Server para SQL Server 2005, tuve la oportunidad de obtener un rendimiento del ahorro de 4 minutos y 21 segundos de tiempo de ejecución y un ahorro de almacenamiento de 543.204 KB.

Tiempo (min) DB Huella

N Mejoras 8:54.141 3,333392 KB
- Aumento de los datos de exclusión 6:32.828 2.857.168 KB
- Aumento de Insertar Aumentar Comprometerse 6:30.750 2.857.168 KB
- Aumento de búfer ajuste 6:20.078 2.857.168 KB
- Aumento de los datos brutos se mueven 6:09.063 2.857.168 KB
- Aumento de mover SQL Server 6:07.718 2.857.168 KB


No hay dos escenarios probables llevará a cabo exactamente el mismo, pero tratando de la totalidad o una combinación de estas prácticas deben rendir grandes resultados.
¡Mucha suerte!

- Añadir el cambio de destino tipo 4:33.344 2.790.188 KB Resumen: Si usted está buscando maneras de mejorar su rendimiento de conversión de datos utilizando Microsoft SQL Server 2005 Integration Services hay una serie de metodologías que se pueden aplicar. Al convertir archivos de gran tamaño EBCDIC, un espectáculo pocas mejorar las técnicas deben ser empleadas en el interés de reducir significativamente el tiempo de ejecución a la vez que con menos capacidad de almacenamiento. Para el ejemplo anterior, las ganancias más altas prestaciones se puede conseguir, modificando el vigente OLE DB destino (un servidor SQL 2000) a un destino de SQL Server (servidor SQL 2005), y mediante la exclusión de datos no deseados desde el flujo de datos.

Excluyendo los datos innecesarios - Esto limita el número de bytes procesados ​​por el motor de SSIS y la huella global de SQL Server.