Sql server SQL Server代理-SSIS包-错误0x80131904-超时已过期

最近在SQL Server代理计划的作业中发生了一系列随机错误，我无法找到解决方案

该错误很少发生，但对于每天计划的作业，通常每周发生一次，但在任意数量的不同作业中，并不总是相同的作业。每个作业都共享一个事实，即它从运行该作业的同一服务器执行SSIS包。它也总是运行30秒，我猜这就是超时阈值。我不知道如果服务器只是连接到自己的SSIS目录，为什么会超时。另外值得注意的是，它从未真正到达执行SSIS包的位置，无论尝试执行哪个包，都会发生这种情况

在我的研究过程中，我遇到许多人建议只需将SQL Server 2012更新为最新的CU*或SP2即可解决问题。但是，尚未将服务器升级到SP2

尝试过的一种解决方案（承认这很难看）是在作业步骤失败时进行一次重试，这实际上在大约30%的情况下解决了问题

我欢迎任何有此错误经验的人，或任何有任何建议的人

错误消息如下所示：

Date        16/07/2014 6:00:11 AM
Log     Job History ({$jobname})

Step ID     1
Server      {$productionserver}
Job Name        {$jobname}
Step Name       {$stepname}
Duration        00:00:31
Sql Severity    0
Sql Message ID  0
Operator Emailed    
Operator Net sent   
Operator Paged  
Retries Attempted   0

Message
Executed as user: {$user}. 
Microsoft (R) SQL Server Execute Package Utility  Version 11.0.5058.0 for 64-bit  Copyright (C) Microsoft Corporation. All rights reserved.    

Started:  6:00:11 AM  Failed to execute IS server package because of error 0x80131904. 
Server: {$productionserver}, 
Package path: {$packagepath}, 
Environment reference Id: NULL.  
Description: Timeout expired.  The timeout period elapsed prior to completion of the operation or the server is not responding.  
Source: .Net SqlClient Data Provider  
Started:  6:00:11 AM  Finished: 6:00:42 AM  
Elapsed:  31.122 seconds.  The package execution failed.  The step failed.

试试这个：

还有这个

---

看起来这是一个已知的错误。

检查包失败时实例上还运行了什么（例如，数据库完整性检查或类似的密集操作）

SQL代理与自己的SSIS目录对话超时（30秒超时）。它实际上并没有执行包，所以它与包本身无关，也与执行时实例有多忙无关

---

（回答这个问题是因为它是在谷歌搜索中出现的）

有时候，当包在SQL集成服务目录下部署两次时，就会发生这种错误。您也可能更改了包名，但还有其他相关的自动生成配置是唯一的，如环境引用Id和其他

因此，如果您有一个计划作业，则需要创建一个新作业并将其指向

---

祝您好运

我们在尝试同时启动多个SSIS包时遇到此错误。服务包本来应该修复它，但没有。我们为SSIS包实施了交错计划，因此在任何给定时刻只有一个包启动

我知道这是一个老问题。但我也有同样的问题，这个问题没有一个公认的答案

作业在1.5秒内失败，因此我认为这不是超时问题

我可以确认0x80131904是（或可能是）权限问题。我的SSIS包在SQL代理作业下运行，具有系统管理员和网络管理员权限。当我将其切换到权限较少的帐户时，我收到了此错误

对我来说，问题是因为我没有在所有正确的位置分配权限。我已经在项目属性中设置了读取/执行权限。然后（这是我没有做的步骤），我必须对包含项目和环境的文件夹分配读取权限

---

希望这对其他人有所帮助。

我们也遇到了同样的错误。作为一种变通方法，我们创建了以下存储过程。如果您将其放入每f.e.10分钟运行一次的作业中，它将确保如果出现随机故障，该作业将持续重新启动，直到达到无超时故障的发生

USE [msdb]
GO

SET ANSI_NULLS ON
GO

SET QUOTED_IDENTIFIER ON
GO


CREATE PROCEDURE [dbo].[usp_StartTimedOutJob]
AS

DECLARE @jobid NVARCHAR(100)
    , @jobname NVARCHAR(250)
    , @stepname NVARCHAR(250)
    , @varMail VARCHAR(MAX)

DECLARE cJobs CURSOR FOR 

-- CTE selects all jobs that are currently not running and orders them by most recent
WITH CTE_NotRunning AS (
    SELECT S.job_id
        , S.step_name
        , S.[message]
        , rownum = ROW_NUMBER() OVER (PARTITION BY S.job_id ORDER BY S.run_date DESC, S.run_time DESC)
    FROM msdb.dbo.sysjobhistory AS S
    LEFT OUTER JOIN (SELECT DISTINCT ja.job_id 
                    FROM msdb.dbo.sysjobactivity ja 
                    LEFT JOIN msdb.dbo.sysjobhistory jh ON ja.job_history_id = jh.instance_id
                    JOIN msdb.dbo.sysjobs j ON ja.job_id = j.job_id
                    JOIN msdb.dbo.sysjobsteps js
                        ON ja.job_id = js.job_id
                        AND ISNULL(ja.last_executed_step_id,0)+1 = js.step_id
                    WHERE
                      ja.session_id = (
                        SELECT TOP 1 session_id FROM msdb.dbo.syssessions ORDER BY agent_start_date DESC
                      )
                    AND start_execution_date is not null
                    AND stop_execution_date is NULL) AS R
                        ON S.job_id = R.job_id
    WHERE R.job_id IS NULL)

-- only select the jobs into the cursor set for which the most recent job had a timeout issue
SELECT job_id
    , step_name
FROM CTE_NotRunning
WHERE [message] LIKE '%0x80131904%time%out%' -- error message that corresponds to timed out jobs, error code: 0x80131904
    AND rownum = 1

OPEN cJobs

    FETCH NEXT FROM cJobs 
        INTO @jobid, @stepname

    WHILE @@FETCH_STATUS = 0
        BEGIN

            -- for each of the timed out jobs in the cursor, start the job again from the step that caused the timeout

                SET @jobname = (SELECT [name] FROM msdb.dbo.sysjobs WHERE job_id = @jobid)

                EXECUTE dbo.sp_start_job @job_id = @jobid, @step_name = @stepname 

        END

CLOSE cJobs

DEALLOCATE cJobs

GO

---

我也有同样的问题。SQL代理运行SSIS作业非常好，但突然我遇到了这个错误。花了大约一个小时在网上寻找修复程序。发现服务器管理员安装了新的windows更新

我只是重新启动了服务器（它承载SSIS目录和SQL Server/Agent）。服务器重新启动后，作业再次正常运行

---

希望服务器重新启动对下一个经历此过程的人有效。

您还想了解更多信息吗？我举了一些我尝试过的例子，错误的频率，事实上它不是每次都发生，也不是总是发生在同一份工作上。我还包括了我收到的完整错误消息。我还可以补充什么？不过就是这样。SSI从一开始就从未执行过，因此代码与此无关。它也发生在几个非常不同的SSIS包上。我想这是我可以在上面提到的一件事，我会把它加进去。在任何我能找到超时的地方，它都被设置为0（无超时），并且它不会执行包，所以我不确定它是否取决于包在做什么。@Ryan你能找到问题的解决方案吗？我和你在同一条船上@Ryan这个问题有什么解决办法吗？同样的场景谢谢，我确实注意到了那个bug报告，并且几乎把它包括在我的描述中，但是在那个bug报告中并没有给出这个错误代码，我不想让人们误入歧途。但是，我尝试了其中一种解决方法（确保服务器没有忙于自动签名数据库），但没有成功。此外，这也暗示SP2将解决问题，但它没有。不过谢谢：）