none
Optimizar una consulta en SSIS para diversas fuentes RRS feed

  • Pregunta

  • Hola a todos.

    Espero que alguno me pueda colaborar con la siguiente duda. Actualmente estoy migrando un ETL de access a SSIS. Una de las consultas involucra datos de una tabla en una base de datos Oracle ubicada en otro servidor.

    El asunto es el siguiente, después de analizar los resultados de access, pude observar que la tabla ubicada en el servidor de SQL no tiene más de 540 registros, mientras que aquella de Oracle tiene más de 18 millones de registros. Al principio intenté realizar la consulta usando un merge join, pero por lo mencionado anteriormente esta aproximación no fue es la más eficiente. Alguien me propuso usar un lookup, pero esta tarea sólo me devuelve un registro cuando encuentra una primera coincidencia, es asunto es que el INNER JOIN que realizo entre ambas tablas debe regresar algo así como 3500 resultados, por ende el lookup tampoco parece ser la mejor alternativa.

    Es por esto que me pregunto si habrá una manera de optimizar esta consulta ya que no puedo entender como en Access resulta ser tan fácil aplicarla y en SSIS tengo tantas dudas con respecto a como organizar la consulta.

    Agradezco su colaboración

    lunes, 6 de abril de 2015 13:14

Todas las respuestas

  • Sin tener datos con los cuales aplicar esto porque haces el sort? esto traerá toda la tabla de Oracle para aplicarlo y creara un gigantesco overhead, si vas a hacer esto seria mejor copiar localmente la tabla de Oracle a un área de staging y trabajarla local.
    • Editado Enrique AA lunes, 6 de abril de 2015 14:15
    lunes, 6 de abril de 2015 13:19
  • Ese es precisamente mi problema, el dba no me permite realizar este tipo de actividades. También les había dicho que la opción más viable era la de crear una copia local de la tabla pero no hay modo de hacer, el por qué?, es un misterio. Es por eso que tuve que realizar la pregunta.
    lunes, 6 de abril de 2015 14:14
  • Intentaste removiendo los orderby, no veo su uso realmente en este punto, no se si tengan una función extra y son operaciones muy costosas.
    lunes, 6 de abril de 2015 14:16
  • Me imagino que te refieres a los sort, si es así, hasta donde tengo entendido es necesario que las tablas usadas en el merge join tengan los campos de unión ordenados para poder realizar esta consulta. De no hacerlo, siempre me resultará un error indicando que falta realizar este orden.
    lunes, 6 de abril de 2015 15:09
  • Hola dj2907, 

    Es un problema bastante común el que tienes, y con todas las condiciones que mencionas, es cierto que tu mejor opción es llevarte el dato a una zona de staging donde vuelques el dato, indexes la tabla por la clave de ordenación que necesitarás después para hacer el INNER JOIN y cuando acabes el proceso trunques la tabla para ahorrar espacio (TRUNCATE TABLE nombre_tabla). 

    La opción que te da Enrique es válida cuando ambos origenes son SQL Server y tienen la misma collation (intercalación). Esto es, te será muy útil cuando tengas la tabla de staging en tu entorno SQL Server desde Oracle. 

    Si no es así, no podrás asegurar que el Merge Join funcione correctamente, porque aunque el metadato de SSIS diga que la ordenación es la misma (con las propiedades del artículo de Enrique) el orden real puede no ser el mismo, ya que diferentes RDBMS (como SQL Server y Oracle) pueden ordenar de manera diferente los mismos datos. El paquete funcionará pero probablemente los resultados de salida del Merge Join no sean correctos. 

    Podrías usar también un Raw File como destino intermedio, pero para asegurar que está ordenado tienes que insertar el dato de esa manera, y si tu origen es un Oracle estás en la misma situación que si cruzases directamente. 

    Como decía, tu mejor opción aquí es la tabla de staging. Negocia con tu DBA una zona horaria con menos carga de trabajo si es necesario, pero no tienes mucha más opción. 

    Un saludo. 

    Pau

    martes, 7 de abril de 2015 10:38