Tridion 无法获取发布队列项目的列表。超时已过期

我在Tridion2009SP1上。在某一点上，查看所有用户的发布队列（即不是筛选器）的功能刚刚停止工作。在CM GUI中接收到超时错误：

(80040E31) Timeout expired
Unable to get list of publishing queue items.

SQLUtilities.OpenRecordsetByStoredProcedure
SystemDAL.GetListData
SystemBLST.lObjListPublishTransactions
SystemBLST.IBLSystemST_GetListData
ManagementInfo.GetListPublishQueue
Request.GetList

因此，我尝试使用发布队列管理器Powertool清理队列，但这只会引发500个错误，这与队列中的项目过多一致

然后，我尝试使用Tridion Purge工具清除队列，但它会嘎吱嘎吱几秒钟并返回相同的错误：

14-May-2012 21:10:12 Log cleared.
14-May-2012 21:10:12 Purge action started at 14-May-2012 21:10:12
14-May-2012 21:10:12 Keeping the last 5 versions.
14-May-2012 21:10:12 Recursive mode: False
14-May-2012 21:11:12 FAILED: <?xml version="1.0"?>
<tcm:Error xmlns:tcm="http://www.tridion.com/ContentManager/5.0" ErrorCode="80040E31" Category="7" Source="Kernel" Severity="1">
    <tcm:Line ErrorCode="80040E31" Cause="false" MessageID="4613"><![CDATA[Unable to get list of publishing queue items.]]>
        <tcm:Token>RESID_4485</tcm:Token>
        <tcm:Token>RESID_15821</tcm:Token>
    </tcm:Line>
    <tcm:Line ErrorCode="80040E31" Cause="true">
        <![CDATA[Timeout expired]]>
    </tcm:Line>
    <tcm:Details>
        <tcm:CallStack>
            <tcm:Location>SQLUtilities.OpenRecordsetByStoredProcedure</tcm:Location>
            <tcm:Location>SystemDAL.GetListData</tcm:Location>               
            <tcm:Location>SystemBLST.lObjListPublishTransactions</tcm:Location>
            <tcm:Location>SystemBLST.IBLSystemST_GetListData</tcm:Location>
            <tcm:Location>ManagementInfo.GetListPublishQueue</tcm:Location>
        </tcm:CallStack>
     </tcm:Details>
</tcm:Error>

2012年5月14日21:10:12日志已清除。
2012年5月14日21:10:12清洗行动于2012年5月14日21:10:12开始
2012年5月14日21:10:12保留最后5个版本。
2012年5月14日21:10:12递归模式：错误
2012年5月14日21:11:12失败：
住宅4485
住宅楼15821
SQLUtilities.OpenRecordSetByStoredProcess
SystemDAL.GetListData
SystemBLST.lObjListPublishTransactions
SystemBLST.IBLSystemST\u GetListData
ManagementInfo.GetListPublishQueue

事件日志都显示完全相同的错误。哦，是的，我尝试重新启动COM+、发布服务器和传输服务

---

因此，发布队列似乎处于不可访问状态。请您说明原因或我的下一步措施好吗？

SQLServer和Internet Information Server的超时设置是什么？如果它们处于股票违约状态（无法立即记住它们是什么），那么可能值得尝试增加它们

---

如果仍然失败，也许可以对数据库进行跟踪，以了解为什么需要这么长时间。

也许可以查询发布事务表，以获取所有事务的tcm uri列表，将其移动到自定义数据库中，并使用TOM.NET API/Core服务单独打开每个事务，并根据状态使用API将其删除

---

通过这种方式，您可以以可控的方式删除事务，而无需直接处理数据库。

您可以尝试许多方法

代码：

将数据集减少到特定的时间段（每周、每月）

逐个选择特定的统计类型（失败、成功等）

关于基础设施：

我不确定您正在尝试做什么，但是如果您只是删除事务，可能只是使用清除工具（但是在编写代码时，我假设它对于您的用例来说不够聪明）

使用清除工具删除与用例无关的旧事务

确保数据库已完全优化

（如上所述）增加Tridion配置管理单元中的超时

确保您的Tridion版本有最新的补丁（2009 GA和SP1的队列性能都有很多变化）

一般来说，确保硬件正在运行

---

我认为，这可能是由于

'N'

发布队列中的

正在进行的
项目的数量造成的

不要试图一次删除所有项目

最好按以下顺序删除队列项目：-

失败
进行中
除此之外，刚才我看到了一个修补程序

修补程序：CM_2009.1.74381

看看这个。
除了这里列出的所有优点之外，您是否优化了数据库？。您应该计划定期更新数据库统计数据，并重新编制索引。请与DBA联系，以安排维护计划

除了定期清理/清除事务外，快速更新CM DB（MSSQL:sp_updatestats）上的统计数据将有助于提高GUI的总体性能

您可以查看Tridion维护文档
在您将大量项目转储到队列中之前，恢复CM数据库的备份。这并不漂亮，但它可能会让您达到目的

否则，请咨询Tridion支持部门，了解他们可能会批准哪些数据库脚本来解决此问题。
当您筛选列表时，您是否能够正确地得到它？对大多数用户来说，是的。但是，当我筛选自己（通过批处理作业发布一百万个项目，从而使队列混乱的人）时，它也会超时。DB维护（或缺少）通常是此类错误的罪魁祸首。感谢Arjen。在Tridion 2009中，核心服务不存在。根据您的建议，我尝试使用TOM COM+API。简单的程序循环通过每个Tridion用户[foreach（tdse.GetUsers（）中的用户u]，获取了他们的事务列表，并逐个删除了事务。但是，当尝试检索任何项目过多的用户的列表时，GetListPublishTransactions（queueFilter）函数因超时而失败。这会导致SQL Server查询超时设置，我在获得DBA后将尝试该设置。通过直接数据库查询获取发布事务的TCM URI列表如何？然后您仍然可以通过API删除它们（因此不会在数据库上遇到支持问题）。+1“使用清除工具删除旧事务“，尽管我怀疑它会遇到相同的超时。嗨，Nickoli。您知道列出的项目中的哪个项目或项目组合修复了问题吗？我们也有相同的问题，我怀疑优化数据库和清除发布队列将有助于此，但希望您提供反馈。谢谢，