Solucionar problemas de ejecución de paquetes SSIS usando el Agente SQL Server (vídeo de SQL Server)

Se aplica a: Microsoft SQL Server Integration Services

Autora: Carla Sabotta, Microsoft Corporation

Duración: 00:12:12 Tamaño: 9.50 MB Tipo: WMV

Ver este vídeo

Temas de ayuda relacionados: Un paquete SSIS no se ejecuta cuando lo llama desde un paso de trabajo del Agente SQL Server dtexec (utilidad) Cómo agregar una configuración de paquetes Establecer el nivel de protección de los paquetes Usar funciones de Integration Services

Otros vídeos: Cómo automatizar la ejecución de paquetes SSIS usando el Agente SQL Server (vídeo de SQL Server)

Resumen del vídeo

Este vídeo enseña cómo solucionar el problema de un paquete de SQL Server Integration Services que no se ejecuta cuando lo llama desde un paso de trabajo del Agente SQL Server . El paquete se ejecuta correctamente fuera del Agente SQL Server.

Transcripción del vídeo

Marca de tiempo del vídeo	Audio
00:00	Hola, soy Carla Sabotta y Redacto la documentación del producto Microsoft SQL Server Integration Services. En este vídeo le mostraré cómo solucionar el problema de un paquete de SQL Server Integration Services que no se ejecuta cuando lo llama desde un paso de trabajo del Agente SQL Server . El paquete se ejecuta correctamente fuera del Agente SQL Server. Aprenderá los métodos recomendados para resolver este problema, incluyendo la creación de una cuenta de proxy, la modificación del valor de la propiedad ProtectionLevel del paquete, guardar la información confidencial en un archivo de configuración de paquete y almacenar un paquete en la base de datos msdb de SQL Server. Como puede ver, este trabajo no logró ejecutar el paquete Integration Services. Cuando llama a un paquete desde un paso de trabajo del Agente SQL Server y el paquete no se ejecuta, una de las siguientes condiciones es cierta: La cuenta de usuario que ejecuta el paquete como un paso de trabajo se diferencia del autor del paquete original. O bien La cuenta de usuario no tiene los permisos requeridos para realizar conexiones o para obtener acceso a los recursos que están fuera del paquete Cuando la cuenta de usuario que llama al paquete desde el paso de trabajo es diferente del autor del paquete original, el nivel de protección del paquete puede impedir que se ejecute. Ello es así porque la cuenta de usuario no puede descifrar el paquete o la información confidencial del paquete, o porque la cuenta de usuario no puede proporcionar la información confidencial que está ausente en el paquete. Ejemplos de información confidencial son la parte de la contraseña de una cadena de conexión, una variable marcada como confidencial, etc. Hay un par de métodos recomendados para resolver los problemas del cifrado y la información confidencial.
01:53	El primer método consiste en almacenar el paquete en la base de datos msdb de SQL Server, configurando el nivel de protección en Basar el control de acceso en funciones y almacenamiento del servidor (Rely on server storage and roles for access control). Para hacerlo, use el servicio Integration Services de SQL Server Management Studio. Ahora son las funciones de la base de datos las que controlan el acceso de lectura y escritura al paquete. Necesita asignar una de las funciones fijas de nivel de base de datos de Integration Services o asignar una función de nivel de base de datos definida por el usuario a la función de lector del paquete. Las funciones fijas de nivel de base de dato son db_ssisadmin, db_ssisoperator y db_ssisltduser. En esta demostración, asignaremos la función db_ssisadmin al paquete. Si asigna una función fija de nivel de base de datos al paquete, la cuenta de usuario que llama al paquete desde el paso de trabajo debe ser miembro de esa función. Si asigna una función definida por el usuario al paquete, la cuenta de usuario debe ser miembro de una de las funciones fijas de nivel de base de datos y miembro de la función definida por el usuario.
03:59	El segundo método consiste en cambiar el valor de configuración de propiedad del paquete ProtectionLevel en EncryptSensitiveWithPassword, en Business Intelligence Development Studio. Obtiene acceso a la propiedad ProtectionLevel del paquete haciendo clic en cualquier parte del flujo de control del paquete y seleccionando, a continuación, ProtectionLevel en la ventana Propiedades (Properties). Después, modifique la línea de comando del paso de trabajo del Agente SQL Server para que incluya la contraseña que descifra la información confidencial. Agregue la contraseña utilizando el parámetro /Decrypt de la utilidad del símbolo del sistema dtexec. Los pasos de trabajo del Agente SQL Server usan la utilidad dtexec para ejecutar los paquetes.
05:22	El tercer método para resolver los problemas del cifrado y los datos confidenciales consiste en cambiar el valor de la propiedad ProtectionLevel del paquete a DontSaveSensitive, utilizando de nuevo Business Intelligence Development Studio. Con este valor de configuración de propiedad, el paquete ya no está cifrado y la información confidencial no se guarda ya en el paquete. Por tanto, use un archivo de configuración de paquete para guardar los datos. En esta demostración, guardaremos la parte de la contraseña de una cadena de conexión para la administración de conexiones DestinationConnectionOLEDB. Cuando los pasos de trabajo del Agente SQL Server ejecutan el paquete, la información confidencial se carga desde el archivo de configuración que se ha creado. No olvide guardar el archivo en una carpeta segura. Hasta ahora, hemos examinado los métodos para resolver problemas de cifrado e información confidencial. La otra condición por la que un paso de trabajo del agente no logra ejecutar un paquete concierne a los permisos de la cuenta de usuario. La cuenta de usuario no tiene los permisos requeridos para realizar conexiones o para obtener acceso a los recursos que están fuera del paquete.
08:08	Para comprobar los permisos de la cuenta de usuario, abra una ventana del símbolo del sistema y ejecute el comando RunAs. Sustituya midominio\miusuario por la información de autenticación almacenada en la credencial de la cuenta. Escriba la contraseña de la cuenta cuando se le pida. El método recomendado para resolver el problema de los permisos consiste en crear una cuenta de proxy del Agente SQL Server que tenga los permisos requeridos. La cuenta de proxy también descifra la información confidencial del paquete. Tenga en cuenta que este método no se realizará correctamente si mueve el paquete a otro equipo y la propiedad ProtectionLevel del paquete está configurada en EncryptSensitiveWithUserKey o en EncryptAllWithUserKey.
09:12	Para crear una cuenta de proxy, usted debe ser miembro de la función fija de servidor sysadmin. O bien, debe ser miembro de SQLAgentOperatorRole, SQLAgentReaderRole o SQLAgentUserRole en la base de datos msdb. Cree una cuenta de proxy ejecutando una consulta Transact-SQL o usando el cuadro de diálogo Nueva cuenta de proxy (New Proxy Account) en SQL Server Management Studio. Usaremos el cuadro de diálogo Nueva cuenta de proxy (New Proxy Account). En la página General, especifique el nombre y las credenciales de la nueva cuenta de proxy. Daremos a esa cuenta el nombre Paquete de proxy (Package proxy) y seleccionaremos una credencial existente, llamada User1, que contiene la información de autenticación. Tenga en cuenta que la credencial debe habilitar al Agente SQL Server para ejecutar el trabajo como la cuenta que creó el paquete o como una cuenta que tiene los permisos requeridos. También necesita especificar un subsistema para el que el proxy esté habilitado. Como el trabajo está ejecutando un paquete, seleccionaremos el subsistema Paquete SQL Server Integration Services (SQL Server Integration Services Package). La descripción del proxy es opcional. En la página Entidades de seguridad (Principals) puede agregar o eliminar funciones para conceder el acceso a la cuenta de proxy. Los miembros de la función fija de servidor sysadmin tienen acceso automático. La credencial User1 que especificamos para la cuenta de proxy está enumerada bajo el nodo Credenciales (Credentials) del Explorador de objetos (Object Explorer). Puede crear una credencial nueva ejecutando una consulta Transact-SQL o usando el cuadro de diálogo Nuevas credenciales (New Credentials). Este vídeo mostró cómo resolver problemas de un paquete que no se ejecuta cuando es llamado desde un paso de trabajo del Agente SQL Server. El vídeo ha tratado los temas de la creación de una cuenta de proxy, la modificación de la configuración de la propiedad ProtectionLevel del paquete, el modo de guardar la información confidencial en un archivo de configuración de paquete y cómo almacenar un paquete en la base de datos msdb de SQL Server. Gracias por su atención. Esperamos que la presentación haya sido de su interés y vuelva a visitar el sitio web para ver otros vídeos de Microsoft SQL Server.