sql server - examples - En SSIS, ¿cómo obtengo el número de filas devueltas de la fuente que DEBERÍA procesarse?
ssis variables in sql command (4)
Estoy trabajando en un proyecto para agregar el registro a nuestros paquetes de SSIS. Estoy haciendo mi propio registro personalizado implementando algunos de los controladores de eventos. Implementé el evento OnInformation para escribir la hora, el nombre de la fuente y el mensaje en el archivo de registro. Cuando los datos se mueven de una tabla a otra, el evento OnInformation me dará un mensaje como:
el componente "TABLENAME" (1) "escribió 87 filas.
En el caso de que falle una de las filas, y digamos que solo se procesaron 85 filas fuera de las esperadas 87. Asumiría que la línea anterior leería wrote 85 rows . ¿Cómo puedo rastrear cuántas filas DEBERÍA HABER procesado en este caso? Me gustaría ver algo así como wrote 85 of 87 rows . Básicamente, creo que necesito saber cómo obtener el número de filas devuelto por la consulta de Source. ¿Hay una forma fácil de hacer esto?
Gracias
Lo que quieres es la transformación del recuento de filas . Simplemente agréguelo a su flujo de datos después de su consulta fuente, y asigne su salida a una variable. Luego puede escribir esa variable en su archivo de registro.
No hay suficiente espacio en los comentarios para proporcionar comentarios. Publicar una respuesta incompleta ya que tengo que irme por el día.
Tendrá problemas para lograr lo que está pidiendo. En función de sus comentarios en la respuesta de Gowdhaman008, el valor de una variable no es visible fuera de un flujo de datos hasta después de que se dispara el evento del finalizador (creo que es OnPostExecute). Puede hacer trampa y obtener esos datos mediante el uso de una tarea de secuencia de comandos para contar filas y disparar eventos, personalizados o predefinidos, para informar el progreso del paquete. De hecho, solo captura el evento OnPipelineRowsSent . Eso registrará cuántas filas están pasando a través de una coyuntura particular y el tiempo que lo rodea. SSIS Performance Framework Plus, no tiene que hacer ningún trabajo o mantenimiento personalizado en sus cosas. La funcionalidad fuera de la caja es una victoria definitiva.
Dicho esto, en realidad no sabrá cuántas filas están saliendo de una fuente hasta que esté terminada. Eso suena estúpido y estoy completamente de acuerdo, pero es la verdad. Imagine un caso simple, un origen de OLE DB que va a enviar 1,000,000 de filas directamente a un destino OLE DB. Lo más probable es que no todas las filas de 1M comiencen en la tubería, quizás solo 10k estarán en el primer buffer. Esos búferes se envían al destino y ahora sabe que se procesaron 10k filas de 10k filas. Enjabona, enjuaga, repite algunas veces y en este buffer, una fila tiene un NULL donde no debería. Boom va la dinamita y el proceso falla. Hemos tenido 60k filas en la tubería y eso es todo lo que sabemos debido a la falla.
La única forma de garantizar que hemos contabilizado todas las filas fuente es colocar una transformación asíncrona en la tubería para bloquear todos los componentes posteriores hasta que todos los datos hayan llegado. Esto borrará cualquier oportunidad que tenga de obtener un buen rendimiento de sus paquetes. Aún estaría sujeto a las restricciones antes mencionadas sobre la actualización de variables, pero su mensaje FireXEvent describiría con precisión cuántas filas se podrían haber procesado en la cola.
Si inició una transacción explícita, podría hacer algo feo como ejecutar una tarea SQL solo para obtener el recuento esperado, escribirlo en una variable y luego registrar las filas procesadas, pero luego deberá consultar sus datos y aumentará la probabilidad de bloqueo. en el sistema fuente debido a la doble bomba. Y eso solo va a funcionar para algo como una base de datos. El mismo concepto se aplicaría a un archivo plano, excepto que ahora necesitaría una tarea de script para leer todas las filas primero.
Donde esto se pone más feo es para una fuente de datos de arranque lenta, como un servicio web. El tamaño predeterminado del búfer puede hacer que todo el paquete se ejecute mucho más tiempo de lo necesario ya que estamos esperando que lleguen los datos. Inicia lentamente
Lo que haría
Grabaría mis conteos de inicio y error (y más) usando el recuento de filas. Esto lo ayudará a dar cuenta de todos los datos que ingresaron y adonde fueron. Luego OnPipelineRowsSent evento OnPipelineRowsSent para permitirme consultar el registro y ver cuántas filas están fluyendo a través de AHORA MISMO.
Puede usar la Row Count transaformation después de la fuente de datos y guardarla. Esta será la cantidad de filas que se procesarán. Una vez que se cargó en el Destino, debe usar la Execute SQL Task en Control flow y usar Select Count(*) from <<DestinationTable>> Execute SQL Task Select Count(*) from <<DestinationTable>> y guardar el conteo en la Otra variable [Debe usar la cláusula Donde en su consulta para identificar la carga actual]. Por lo tanto, tendrá filas numéricas procesadas para el registro.
¡Espero que esto ayude!
Esto PUEDE ayudar si tiene una columna que no tiene datos incorrectos. Agregue un segundo origen de archivo plano al paquete. Use la misma conexión que su fuente de archivo existente. Elija la primera columna solamente y dirija la salida a un recuento de filas.