SQL Server procedimiento almacenado conversión a paquete SSIS

Question

Problema: actualmente tenemos numerosos procedimientos almacenados (muy larga hasta 10,000 líneas) que fueron escritos por varios desarrolladores para varios requisitos en los últimos 10 años. Ahora es difícil administrar esos procedimientos almacenados complejos/largos (sin la documentación adecuada).

Planeamos mover esos procedimientos almacenados en el paquete SSL ETL.

¿Alguien ha hecho esto? En caso afirmativo, ¿qué enfoque debería uno tomar?

Apreciar si alguien puede ofrecer asesoramiento sobre el enfoque para convertir el procedimiento almacenado en paquetes SSIS ETL.

Gracias

Answer 1

que he hecho esto antes, y lo que funcionó bien para mi equipo estaba refactorizar gradualmente, comenzando por la fuente original, y luego repetir el esfuerzo refactorización.

El primer paso fue intentar modularizar la lógica del procedimiento almacenado en las tareas de ejecución de SQL que encadenamos juntas. Cada tarea fue probada y aprobada, luego integramos y aseguramos que el nuevo proceso coincidiera con los resultados de los procedimientos heredados.

Después de este punto, podríamos dividir las tareas individuales de Ejecutar SQL en todo el equipo, y equilibrar la carga del análisis de si podríamos refactorizar aún más el SQL dentro de las tareas Ejecutar SQL a las tareas nativas de SSIS.

Cada refactorización se probó individualmente por unidad y luego se probó la integración para garantizar que la salida general del proceso aún se comportara como los procedimientos heredados.

Answer 2

Yo sugeriría los siguientes pasos:

1. analizar los procedimientos almacenados para identificar la lista de fuentes y destinos. Por ejemplo: si el procedimiento almacenado dbo.TransferOrders mueve los datos de la tabla dbo.Order a dbo.OrderHistory. Entonces su fuente será dbo.Order y el destino será dbo.OrderHistory.

2. Después de enumerar las fuentes y los destinos, intente agrupar los procedimientos almacenados según su preferencia por origen/destino.

3. Trate de averiguar si hay alguna transformación de datos dentro de los procedimientos almacenados. Hay buenas tareas de transformación de datos disponibles dentro de SSIS. Puede evaluar y mover algunas de esas funcionalidades de procedimientos almacenados a SSIS. Como SSIS es un tipo de herramienta de flujo de trabajo, creo que es más fácil entender lo que está pasando dentro del paquete que tener que desplazarse por muchas líneas de código para comprender la funcionalidad. Pero, ese soy solo yo. Las preferencias difieren de persona a persona.

4. Trate de identificar las dependencias dentro de los procedimientos almacenados y prepare una jerarquía. Esto ayudará a colocar las tareas dentro del paquete en el orden apropiado.

5. Si tiene una tabla llamada dbo.Table1 que rellena 5 tablas diferentes. Yo recomendaría tenerlos en un solo paquete. Incluso si esta población de datos se lleva a cabo mediante 5 procedimientos almacenados diferentes, no necesita ir por 5 paquetes. Aún así, esto nuevamente depende de su situación comercial.

6. La solución del proyecto SSIS puede tener múltiples paquetes dentro de ellos y reutilizar las fuentes de datos. Puede usar Execute SQL task disponible en la tarea Control Flow para ejecutar sus consultas existentes, pero le recomendaría que también consulte algunas de las agradables tareas de transformación disponibles en SSIS. Los he usado en mi proyecto y funcionan bien para las operaciones de ETL.

Estos pasos se pueden realizar al buscar en un procedimiento almacenado a la vez. No tiene que pasar por todos a la vez.

Eche un vistazo a algunos de los ejemplos que he proporcionado en otras preguntas sobre desbordamientos de pila. Esto debería ayudarlo a dar una idea de lo que puede lograr con SSIS.

Copying data from one SQL table to another

Logging feature available in SSIS

Loading a flat file with 1 million rows into SQL tables using SSIS

Espero que ayude.