Question

最近，我将Documentum系统从Documentum 6.5升级到MS SQLServer数据库上的Documentum 6.7。对于6.5，我们使用32位SQLServer并移动到64位SQLServer 6.7。自升级以来，我面临着几乎在6.5上立即运行的DQL语句的非常糟糕的性能。

现在在6.7上表现不佳的DQL示例：

SELECT r_object_id, object_name, title, keywords 
  FROM dm_folder
 WHERE object_name LIKE 'MOC -10-%'
  AND NOT r_object_id IN
(SELECT i_folder_id FROM dm_document WHERE ANY i_folder_id = dm_folder.r_object_id AND     ANY keywords IS NOT NULLSTRING)
 ORDER BY 1 DESC

进行一些研究和跟踪，我了解到Documentum 6.7生成的SQL语句要慢得多，并且使用SQL查询分析器可以大大改进。我在D6.5上的查询运行时间不到3秒，但在D6.7上运行时间为368秒！当我抓住在D6.7 DQL上生成的SQL并将其传递到运行D6.5系统的SQLServer时，性能也很糟糕。它确实告诉我底层数据模型没有改变，因为我没有在D6.5 SQL数据库上得到错误。抓住D6.5生成的SQL并将其粘贴到D6.7 SQLServer上可以获得与6.5查询相同（甚至更好一点）的性能。为了确保不要混淆：

D6.5 DQL生成的SQL在6.5 SQLServer = 2.5秒
由D6.7 DQL生成的SQL在6.7 SQLServer = 368秒
D6.5 DQL生成的SQL在6.7 SQLServer = 2.5秒或更短时间内运行
D6.7 DQL生成的SQL在6.5 SQLServer = 368秒或更长时间运行

Documentum有一份针对D7CS的性能白皮书，在使用MS SQLServer时建议使用以下参数： DM_LEFT_OUTER_JOIN_FOR_ACL = T

在CS6.7文档中我也发现了这个参数，在环境变量中设置它并重新启动服务器会有一些改进，但结果仍然太慢。 SQL调优工具仍然无法改进生成的SQL，在我看来生成的SQL中有太多的OR语句。

有没有人遇到过类似的问题？并且知道我忽略的修复或魔法配置参数？

由于

Jacques＆＃34; Plafond＆＃34;

Answer 1

当您仍然可以访问较旧和较新的Documentum系统时，您可以获得查询的SQL转换（通过Delilah for Documentum等工具），您可以比较生成的SQL是否发生了很大变化。

您是否将Documentum数据库转换为Unicode？这将使您的数据乘以2并对性能产生影响。

Answer 2

带SELECT i_folder_id FROM dm_document WHERE...的子选择（ANY）将成为一个问题。你可以重写一下，这样你就不会强迫SQL Server处理它吗？

与Documentum 6.5相比，Documentum 6.7 DQL到SQL的转换要慢得多

现在在6.7上表现不佳的DQL示例：

2 个答案: