Долгая работа поиска в Менеджерах структур при поиске по заметкам вхождения (occurrence notes). Кто-нибудь сталкивался?

[NeedMoreLODs 81]

При поиске по заметкам вхождений в Менеджере структур или в Менеджере многовидовых структур этот самый поиск работает довольно долго.

 

Для примера - при поиске в тестовой сборке с двумя occurrence по "UG GEOMETRY" EQ "NO" поиск работал несколько минут (occurrence с UG GEOMETRY = NO в сборке всего один).

На хоть сколько то больших сборках результата чего-то пока не дождался.

При том что в целом со скоростью работы поиска по другим параметрам проблем никаких нет.

 

Это нормально для данного вида поиска ("Заметки о вхождениях")?

Если нет, то кто-нибудь сталкивался с такой проблемой?

Если проблему решили, то от чего зависит скорость работы данной разновидности поиска?

[lexx174 373]

За данный поиск не скажу,но вообще - тимцентр в плане поиска всегда отличался тормозами,и не только в поиске.

Здесь разве что тюнинг СУБД в помощь. Но мне не довелось найти стоящий материал или пообщаться с гуру на тему настроек СУБД(напр.oracle) для реального улучшения быстродействия поиска и других операций в тимцентре.

Но более 50% тормозов в TC связано с быстродействием обработки запросов субд. Это и сименс не отрицает.

Изменено 5 апреля 2017 пользователем lexx174

[NeedMoreLODs 81]

1 час назад, lexx174 сказал:

За данный поиск не скажу,но вообще - тимцентр в плане поиска всегда отличался тормозами,и не только в поиске.

Насчёт тормозов в целом согласен, иногда даже очень согласен.

Но залезть в кишки Teamcentr'а я не могу, т.к. не админ.

 

Просто тут случай странный - тормоза даже на примитивнейшей сборке всего из двух компонент (думаю даже на сборке с одним компонентом будет то же самое).

 

Вообще я достаточно простую задачу пытаюсь решить.

Задача не то чтобы критическая, просто мне непонятны причины тормозов.

 

Предположим есть некая сборка, созданная в NX.

В этой сборке есть некоторые экземпляры компонент с установленным в свойствах флажком (в русской локализации) "Компонент является негеометрическим".

Уже в менеджерах структур в этой самой структуре сборки все эти негеометрические компоненты надо бы найти ("маппинг" этого NX'овского флажка идёт в occurrence notes в "UG GEOMETRY") в поиске.

В принципе, как я вижу, поиск то по заметкам вхождений работает.

Но работает меееееедлено даже там, где тормозить просто негде.

 

Может кто-то сталкивался с тормозами именно при поиске по заметкам и знает в чём дело.

Изменено 5 апреля 2017 пользователем Алексей256

[Ownd_hard 6]

@Алексей256 А версия ТС какая у вас?

[NeedMoreLODs 81]

Только что, Ownd_hard сказал:

 А версия ТС какая у вас?

Teamcenter 9.

[Mazzi 8]

20 минут назад, Алексей256 сказал:

Но работает меееееедлено даже там, где тормозить просто негде.

Для начала, устанавливаете значение переменных

Цитата

set TC_KEEP_SYSTEM_LOG=TRUE
set TC_SLOW_SQL=1

и смотрите время выполнения SQL-запросов в *.syslog файлах (в папке, на которую указывает переменная окружения %TEMP%). Смотрите какой запрос тормозит и занимаетесь оптимизацией СУБД

Изменено 5 апреля 2017 пользователем Mazzi

[NeedMoreLODs 81]

Нет у меня доступа к серверной части.

 

P.S.: Поиск по сборке из единственного элемента занимает почти две минуты. Если кто-то сталкивался именно с таким и решил/не решил проблему - неплохо если бы поделились опытом.

[Mazzi 8]

1 час назад, Алексей256 сказал:

Нет у меня доступа к серверной части.

Описанные мной действия делаются на клиенте , за исключением тюнинга СУБД

Изменено 6 апреля 2017 пользователем Mazzi

[NeedMoreLODs 81]

47 минут назад, Mazzi сказал:

Описанные мной действия делаются на клиенте , за исключением тюнинга СУБД

А вот за это замечание дважды спасибо! :-)

Попозже попробую - если что-то выяснится - отпишусь - вдруг кому-то пригодится.

[Mazzi 8]

Мы сталкиваемся с подобным в Teamcenter Engeenering. Если позиция в сборке имеет большое количество вхождений (использований) в других сборках и на эту позицию назначались значения заметок ВОМ-а в контексте, то все, атас: там запросы написаны таким образом, что сначала получает из таблицы вхождений ВСЕ вхождения для необходимой позиции, а потом перебором определяет необходимую.

Может быть в новых версиях ТС что-то и поменялось в этом плане, не тестировал.

[NeedMoreLODs 81]

56 минут назад, Mazzi сказал:

Мы сталкиваемся с подобным в Teamcenter Engeenering. Если позиция в сборке имеет большое количество вхождений (использований) в других сборках и на эту позицию назначались значения заметок ВОМ-а в контексте, то все, атас: там запросы написаны таким образом, что сначала получает из таблицы вхождений ВСЕ вхождения для необходимой позиции, а потом перебором определяет необходимую.

 

Посмотрел я краешком глаза на код SQL-запроса по своему поиску.

По определённым причинам код привести не могу.

Но кажется, что ситуация похожа на ту, что вы описали.

 

Запрос как-то странно составлен, выборка сразу из нескольких таблиц, с кучей AND и т.д.

Похоже что Teamcenter сначала заставляет СУБД обработать все occurrence (и другие сопутствующие объекты) в БД, а потом уже по результирующему набору смотрит совпадения с теми заметками, ревизиями item'ов и вхождениями, что попали в рантайме в менеджеры структур.

Хотя я думал, что заход должен быть с другого конца (со стороны тех объектов, что попали в рантайме в BOMLine и т.д.).

 

Похоже что проблема скорее фундаментальная и заключается не в оптимизации БД.

 

Ну и ладно, перебьюсь пока без таких поисков.

Изменено 7 апреля 2017 пользователем Алексей256