Documentum 6.7 Перевод DQL в SQL намного медленнее по сравнению с Documentum 6.5

Question

Недавно я обновил свою систему Documentum с Documentum 6.5 до Documentum 6.7 в базе данных MS SQLServer. Для 6.5 мы использовали 32-битный SQLServer и перешли на 64-битный SQLServer для 6.7. После обновления я столкнулся с очень плохой производительностью для операторов DQL, которые почти мгновенно запускаются на 6.5.

Пример DQL, который сейчас плохо работает на 6.7:

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

Проведя некоторое исследование и отслеживание, я узнал, что операторы SQL, генерируемые Documentum 6.7, намного медленнее и не могут быть значительно улучшены с помощью SQL Query Analyzer. У меня есть запросы, которые выполняются менее чем за 3 секунды на D6.5, но занимают 368 секунд на D6.7! Когда я беру SQL, сгенерированный на D6.7 DQL, и вставляю его в SQLServer, на котором работает система D6.5, производительность также плохая. Я узнал, что базовая модель данных не изменилась, потому что я не получаю ошибок в базе данных SQL D6.5. Захват сгенерированного D6.5 SQL и вставка его в D6.7 SQLServer дает ту же (или даже немного лучшую) производительность, что и запрос 6.5. Чтобы убедиться, что это не смущает:

• SQL, сгенерированный D6.5 DQL, работает на 6,5 SQLServer = 2,5 секунды
• SQL, сгенерированный D6.7 DQL, работает на 6,7 SQLServer = 368 секунд
• SQL, сгенерированный D6.5 DQL, работает на 6,7 SQLServer = 2,5 секунды или меньше
• SQL, сгенерированный D6.7 DQL, работает на 6,5 SQLServer = 368 секунд или более

В Documentum есть технический документ по производительности для D7CS, который рекомендует использовать следующий параметр при использовании MS SQLServer: DM_LEFT_OUTER_JOIN_FOR_ACL=T

В документации по CS6.7 я также нашел этот параметр, установка его в среде vars и перезапуск сервера дают некоторые улучшения, но результат все еще слишком медленный. Тем не менее, сгенерированный SQL не может быть значительно улучшен средствами настройки SQL, на мой взгляд, слишком много операторов OR в сгенерированном SQL.

Кто-нибудь испытывал подобные проблемы? И знает исправление или магический параметр конфигурации, который я пропустил?

Спасибо

Жак "Плафон"

Answer 1

Если у вас все еще есть доступ к более старым и новым системам Documentum, вы можете получить перевод вашего запроса на SQL (с помощью таких инструментов, как Delilah for Documentum), и вы можете сравнить, сильно ли изменился сгенерированный SQL.

Вы конвертировали свою базу данных Documentum в Unicode? это умножит ваши данные на 2 и повлияет на производительность.

Answer 2

Подвыбор (SELECT i_folder_id FROM dm_document WHERE...) с ANY будет проблемой. Можете ли вы переписать это, чтобы не заставлять SQL Server справиться с этим?