Para el Diseño y Construcción de los procesos de carga (ETL) en un Data Warehouse basado en SQL Server y Transact-SQL (sin herramientas ETL externas, sólo con el motor de base de datos SQL Server), existen diferentes alternativas a utilizar (SELECT INTO, BULK INSERT, INSERT INTO, BCP.EXE, OPENROWSET BULK, etc), cada una de ellas con unas ventajas e inconvenientes, que nos obligan a tener que elegir cuál es la mejor solución para cada caso.
Si los datos de origen ya están ubicados en la misma instancia de SQL Server que los datos de destino (indiferentemente de que sean mismas o diferentes bases de datos), podemos utilizar SELECT INTO e INSERT INTO para cargar las tablas destino de nuestro Data Warehouse, siendo esta quizás la alternativa más rápida y sencilla de desarrollar nuestros procesos de carga (y con un excepcional rendimiento, al menos, en el caso de SELECT INTO en el Modo de Recuperación Simple y en el Modo de Recuperación de Copia Masiva, al tratarse de una Operación de Registro Mínimo).
El caso de trabajar con instancias separadas o con orígenes de datos heterogéneos es muy distinto, y queda fuera del alcance de este artículo, aunque es fácil predecir que si deseamos mover datos entre instancias separadas de SQL Server (o entre diferentes orígenes de datos) tendremos que evaluar la utilización de Servidores Vinculados (Linked Servers), OPENROWSET, y por supuesto, descargas y cargas de ficheros (BCP.EXE, BULK INSERT, SELECT INTO FROM OPENROWSET BULK, etc.), y por supuesto tener en cuenta que en función del Proveedor OLEDB, Proveedor .Net, o Driver ODBC utilizado, podremos encontrar grandes diferencias en rendimiento y en funcionalidad.
Para empezar, vamos presentar dichas alternativas básicas (SELECT INTO e INSERT INTO) de una forma unitaria, con el objetivo de conocer sus principales características teóricas, y así obtener una primera base que nos ayude en el diseño y construcción de procesos de carga (ETL) más complejos, mezclando las alternativas aquí expuestas, así como otras soluciones más avanzadas.
El contenido del presente Artículo tiene un carácter genérico, es decir, su alcance no se limita a entornos de Data Warehouse (DW) y Business Intelligence (BI). Sin embargo, es evidente que en este tipo de entornos, toma mayor importancia la optimización de este tipo de operaciones, pues se trata de entornos en los cuales se trabaja con grandes volúmenes de datos (en ocasiones, tablas con cientos de millones de filas), que necesitan leerse, transformarse, e insertarse en el menor tiempo y mejor rendimiento posible.
Puestos en situación, vamos a empezar a estudiar la utilización de SELECT INTO e INSERT INTO, sus consideraciones de consumo de LOG en función del Modo de Recuperación (Recovery) de SQL Server, y otras consideraciones y trucos a tener en cuenta.
Para el Diseño y Construcción de los procesos de carga (ETL) en un Data Warehouse basado en SQL Server y Transact-SQL (sin herramientas ETL externas, sólo con el motor de base de datos SQL Server), existen diferentes alternativas a utilizar (SELECT INTO, BULK INSERT, INSERT INTO, BCP.EXE, OPENROWSET BULK, etc), cada una de ellas con unas ventajas e inconvenientes, que nos obligan a tener que elegir cuál es la mejor solución para cada caso.
Si los datos de origen ya están ubicados en la misma instancia de SQL Server que los datos de destino (indiferentemente de que sean mismas o diferentes bases de datos), podemos utilizar SELECT INTO e INSERT INTO para cargar las tablas destino de nuestro Data Warehouse, siendo esta quizás la alternativa más rápida y sencilla de desarrollar nuestros procesos de carga (y con un excepcional rendimiento, al menos, en el caso de SELECT INTO en el Modo de Recuperación Simple y en el Modo de Recuperación de Copia Masiva, al tratarse de una Operación de Registro Mínimo).
El caso de trabajar con instancias separadas o con orígenes de datos heterogéneos es muy distinto, y queda fuera del alcance de este artículo, aunque es fácil predecir que si deseamos mover datos entre instancias separadas de SQL Server (o entre diferentes orígenes de datos) tendremos que evaluar la utilización de Servidores Vinculados (Linked Servers), OPENROWSET, y por supuesto, descargas y cargas de ficheros (BCP.EXE, BULK INSERT, SELECT INTO FROM OPENROWSET BULK, etc.), y por supuesto tener en cuenta que en función del Proveedor OLEDB, Proveedor .Net, o Driver ODBC utilizado, podremos encontrar grandes diferencias en rendimiento y en funcionalidad.
Para empezar, vamos presentar dichas alternativas básicas (SELECT INTO e INSERT INTO) de una forma unitaria, con el objetivo de conocer sus principales características teóricas, y así obtener una primera base que nos ayude en el diseño y construcción de procesos de carga (ETL) más complejos, mezclando las alternativas aquí expuestas, así como otras soluciones más avanzadas.
El contenido del presente Artículo tiene un carácter genérico, es decir, su alcance no se limita a entornos de Data Warehouse (DW) y Business Intelligence (BI). Sin embargo, es evidente que en este tipo de entornos, toma mayor importancia la optimización de este tipo de operaciones, pues se trata de entornos en los cuales se trabaja con grandes volúmenes de datos (en ocasiones, tablas con cientos de millones de filas), que necesitan leerse, transformarse, e insertarse en el menor tiempo y mejor rendimiento posible.
Puestos en situación, vamos a empezar a estudiar la utilización de SELECT INTO e INSERT INTO, sus consideraciones de consumo de LOG en función del Modo de Recuperación (Recovery) de SQL Server, y otras consideraciones y trucos a tener en cuenta.
