Primera impresión al utilizar Microsoft SQL Server Integration Services (SSIS), la primera impresión del desarrollador es que la herramienta proporciona características de gran alcance además es fácil de usar. Aunque esto es verdad, hay algunos errores comunes que pueden hacernos perder nuestro tiempo. El propósito de este artículo del blog es cubrir algunos de estos problemas muy comunes y ahorrar un poco de tiempo al comenzar a desarrollar una solución con Microsoft SSIS.
As a quick overview, SSIS is a component of Microsoft SQL Server that we can use to perform data integration tasks. Microsoft provides a visual tool for the ETL Development based on Visual Studio called SQL Server Business Intelligence Development Studio.
Componentes:
Solution Explorer: Contains all the project files, mainly: Packages, Folders and Project configuration managers. The configuration managers are just configuration files for providing connectivity to sources (flat files, databases…). There are two types depending on the ownership, package and project connection managers.
Properties tab: Displays properties of the selected item.
Connection managers: Here we have visibility for all the connection managers used by the package (project and package connection managers).
Al tomar los primeros pasos con la herramienta, hay algunos errores comunes que nos pueden hacer perder mucho tiempo y que puede convertirse en un reto una vez que desplegamos la solución en un servidor. Podemos resumir estos problemas en los siguientes puntos:
Configuración del entorno 32 / 64
Niveles de protección
Unidades de red
Configuración del entorno 32 / 64:
La máquina puede no tener 64 bit para Microsoft Excel, Oracle o proveedor de datos ODBC. Para configurar el proyecto a ejecutarse en el modo 32 -bit, debemos configurarlo a través de las propiedades del proyecto. Si vamos a la vista del Solution Explorer, hacemos clic en properties-> debugging, podemos cambiar el modo 64 -bit:
El siguiente paso después de que su desarrollo se hace es probablemente para implementar el ETL en un servidor. El proyecto se implementa en un catálogo de Integration Services en una instancia de SQL Server. El Agente SQL será entonces responsable de ejecutar y programar los paquetes. Todo este proceso se describe detalladamente en el siguiente enlace:
http://technet.microsoft.com/en-us/library/hh231102.aspx
Una vez implementado en el servidor, también podemos probar si esto va a ser ejecutado en 32 o 64 bit (en el extraño caso que el servidor está usando un 32 -bitruntime). Podemos cambiar el modo 32 o 64 si hacemos clic en el archivo job-> properties-> steps-> step property-> 32 -bit runtime.
Niveles de protección
Un proyecto SSIS contiene datos confidenciales para muchos propósitos. Lo más probable es que contenga archivos de gestor de conexión para poder conectarse a diferentes fuentes de datos. En estos archivos, SSIS almacena las credenciales para el origen de datos. Estas credenciales se pueden configurar para cifrar, dependiendo del nivel de protección. SSIS proporciona las siguientes opciones para el nivel de protección:
DoNotUseSensitive: No almacena ninguna información
EncryptAllWithPassword / Encrypt Sensitive con contraseña
Encryptallwithuserkey / encryptsensitivewithuserkey
Almacenamiento del servidor
More details about the protection levels can be found here: http://blogs.prodata.ie/post/SSIS-Package-Protection-Levels-and-their-Usage.aspx
Generalmente no hay muchos problemas al desarrollar en su máquina. Muchos problemas surgen una vez que se implementa el paquete y el agente de SQL intenta leer datos de ellos; Si depura este proceso obtendrá un error de intento de conexión. Cambiar entre estas opciones puede ayudarnos en la solución de problemas.
Sin embargo, los problemas más comunes provienen de una de esas razones:
El nivel de protección es diferente a nivel de proyecto y paquete.
El nivel de protección se configura como cifrado con clave de usuario y el usuario de SQL Agent es diferente del propietario del proyecto.
Podemos cambiar el nivel de protección del paquete dirigiéndonos al flujo de control y en la pestaña Propiedades (abajo a la derecha en la imagen de abajo).
Mientras que el nivel de protección a nivel de proyecto se puede encontrar haciendo clic derecho Proyecto-> Propiedades comunes-> Seguridad -> Nivel de protección.
Siguiendo el mismo procedimiento, podemos ver el nombre de usuario que creó el paquete / proyecto. Si el modo de cifrado está habilitado (por defecto es), entonces debemos asegurarnos de que la propiedad del proyecto / paquetes coincida con el nombre de usuario en el servicio del agente de SQL Server. Podemos acceder a esta información haciendo clic en Control PanelSystem y SecurityAdministrative ToolsServices y luego las propiedades del servicio del Agente SQL-> Iniciar sesión
Unidades de red
A common issue when loading data from flat files appears when these files are located in a shared drive. SQL Agent will not recognize network paths if they are not in UNC format (read more about the UNC in http://compnetworking.about.com/od/windowsnetworking/g/unc-name.htm ), whereas SSIS works fine with them. It may be confusing since when the developer deploys the package in the server everything seems to be fine. But at the time the job executes the SQL agent will report: Path not found error.
Dado que no podemos especificar la ruta UNC con la GUI del SSIS, necesitamos escribirla dentro del archivo XML del gestor de conexiones e introducir manualmente la ruta UNC en la cadena de conexión DTS:
DTS: ObjectName = "Portal Web SOURCE" DTS:DTSID="" DTS: CreationName = "FILE"> DTS: ConnectionString = "dc01fpnv04public $ Mi número Mi IdentityExclusionsWeb portal portal de datosWeb semanal Informe de presentación new1.csv" />
Podemos acceder a este archivo haciendo clic derecho en el gestor de conexiones -> View Code: