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

Недавно я обновил свою систему 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, сгенерированный на DQL D6.7, и передаю его в SQLServer, работающий под управлением системы D6.5, производительность также плохая. Он узнает, что базовая модель данных не изменилась, потому что я не получаю ошибок в базе данных SQL D6.5. Захват сгенерированного D6.5 SQL и вставка его в SQLServer D6.7 дает такую ​​же (или даже немного лучшую) производительность, чем запрос 6.5. Чтобы не запутаться:

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

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

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

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

Спасибо

Жак Плафон


performance sql-server-2008 dql documentum
person Jacques Plafond    schedule 18.03.2014    source источник
comment
Не могли бы вы поделиться с нами сгенерированным SQL из D6.5 и D6.7? Вы создали одинаковые индексы на обоих SQL-серверах? Кроме того, имейте в виду, что написанный вами DQL чрезвычайно дорог, используя два повторяющихся атрибута (ключевое слово ANY), а также используя столбцы из внешнего запроса во внутреннем. Есть ли другой практический подход, скажем, использование двух или трех запросов вместо одного?   -  person eivamu    schedule 19.03.2014
comment
Согласитесь, нам нужно увидеть сгенерированный DQL, потому что вы уже сами провели здесь много исследований. Вы также можете опубликовать это на developer.emc.com.   -  person Brendan Hannemann    schedule 25.03.2014

Ответы (2)


arrow_upward
1
arrow_downward

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

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

person Rob de Leeuw    schedule 12.07.2017

arrow_upward
0
arrow_downward

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

person Content Source    schedule 20.06.2014