Usando el SQL Server Business Intelligence Development Studio, hago muchos archivos planos a los flujos de datos de destino OLE DB para importar datos a mis tablas de SQL Server. En "Modo de acceso a datos" en el editor de destino OLE DB, el valor predeterminado es "tabla o vista" en lugar de "tabla o vista - carga rápida". Cuál es la diferencia; La única diferencia perceptible que puedo percibir es que la carga rápida transfiere los datos mucho más rápido.
Modo de acceso a datos de flujo de datos SSIS: ¿cuál es el punto de 'tabla o vista' frente a carga rápida?
Respuestas:
Los modos de acceso a datos del componente de destino OLE DB vienen en dos tipos: rápido y no rápido.
Rápido, ya sea "tabla o vista - carga rápida" o "variable de nombre de tabla o vista - carga rápida" significa que los datos se cargarán de una manera basada en conjuntos.
Lento: la "tabla o vista" o la "variable de nombre de tabla o vista" dará como resultado que SSIS emita declaraciones de inserción única a la base de datos. Si está cargando 10, 100, tal vez incluso 10000 filas, probablemente haya poca diferencia de rendimiento apreciable entre los dos métodos. Sin embargo, en algún momento va a saturar su instancia de SQL Server con todas estas pequeñas solicitudes. Además, vas a abusar de tu registro de transacciones.
¿Por qué querrías los métodos no rápidos? Malos datos Si enviara 10000 filas de datos y la 9999a fila tenía una fecha de 29/02/2015, tendría 10k inserciones atómicas y confirmaciones / retrocesos. Si estaba usando el método Rápido, todo ese lote de 10k filas se guardará o ninguno. Y si desea saber qué filas se equivocaron, el nivel más bajo de granularidad que tendrá es de 10k filas.
Ahora, hay enfoques para cargar la mayor cantidad de datos lo más rápido posible y aún así manejar datos sucios. Es un enfoque de falla en cascada y se ve algo así como
La idea es que encuentre el tamaño correcto para insertar tanto como sea posible en una sola toma, pero si obtiene datos incorrectos, intentará volver a guardar los datos en lotes sucesivamente más pequeños para llegar a las filas incorrectas. Aquí comencé con un tamaño máximo de confirmación de inserción (FastLoadMaxInsertCommit) de 10000. En la disposición de la fila de error, lo cambio a Redirect Rowdesde Fail Component.
El siguiente destino es el mismo que el anterior pero aquí intento una carga rápida y la guardo en lotes de 100 filas. Nuevamente, pruebe o simule que tiene un tamaño razonable. Esto dará como resultado 100 lotes de 100 filas enviadas porque sabemos que en algún lugar allí, hay al menos una fila que violó las restricciones de integridad para la tabla.
Luego agrego un tercer componente a la mezcla, esta vez guardo en lotes de 1. O simplemente puede cambiar el modo de acceso a la tabla fuera de la versión Fast Load porque producirá el mismo resultado. Guardaremos cada fila individualmente y eso nos permitirá hacer "algo" con la (s) única (s) fila (s) incorrecta (s).
Finalmente, tengo un destino seguro. Quizás sea la "misma" tabla que el destino previsto, pero todas las columnas se declaran como nvarchar(4000) NULL. Cualquier cosa que termine en esa mesa debe investigarse y limpiarse / descartarse o sea cual sea su proceso de resolución de datos incorrectos. Otros vuelven a un archivo plano, pero en realidad, lo que sea que tenga sentido para cómo desea rastrear los datos incorrectos funciona.
La carga rápida está bien documentada en las opciones de CARGA RÁPIDA
Mantenga los valores de identidad del archivo de datos importados o use valores únicos asignados por SQL Server.
Mantenga un valor nulo durante la operación de carga masiva.
Verifique las restricciones en la tabla o vista de destino durante la operación de importación masiva.
Adquiera un bloqueo de nivel de tabla durante la operación de carga masiva. Especifique el número de filas en el lote y el tamaño de confirmación.
Cuál es la diferencia; La única diferencia perceptible que puedo percibir es que la carga rápida transfiere los datos mucho más rápido.
Debajo del capó, table or viewusará un comando SQL individual para cada fila para insertar vs table or view - with fast loadusará el comando BULK INSERT.
Si ve las opciones anteriores que están disponibles en BULK INSERT, por ejemplo, number of rows in the batch= ROWS_PER_BATCHy commit size=BATCHSIZE
Otro escenario será ...
El tamaño predeterminado de confirmación de inserción máxima (2147483647) es demasiado alto. Entonces, por ejemplo, está insertando 500K filas y debido a una violación de PK, el lote falla. En este escenario, todo el lote fallará cuando use la opción CARGA RÁPIDA. Tampoco podrá obtener la descripción del error.
Aquí es donde puede tener table or viewcomo destino Salida de error. Entonces, de 500K, usa FAST LOAD como un comienzo con un tamaño de confirmación de inserción de 5K. Si falla 1 fila en ese lote, redirigirá esos lotes de 5K para table or viewcargar, que utiliza la inserción fila por fila SOLAMENTE para filas de 5K y también puede redirigir el error table or viewa un archivo plano ... de modo que si alguna fila falla el lote Si es 5K, podrá determinar qué causó la falla.
La ventaja del método anterior es que si ninguna de las filas falla, utilizará BULK INSERT (carga rápida) para todo el lote.
El entusiasta de SSIS billinkc respondió una pregunta similar sobre Stackoverflow .