Matrix deadlocks

[ybk]

Всем привет.

Занимаюсь кастомизацией ENOVIA на уровне Matrix: JPO, TCL, MQL команды. Недавно cтолкнулся с проблемой блокировок.
Использую стандартные MQL команды: copy, delete, add, connect. Проблема возникает при параллельном выполнении множества команд.
Как правило, когда возникает deadlock, активно используется команда delete, и deadlock в таком случае возникает не только для delete, а и для других параллельно выполняющихся команд.
Поисследовал немного проблему - deadlock возникает чаще в ситуациях, когда к businessobject добавлены какие-либо файлы.
Собственные транзакции не использую.
Может кто-нибудь сталкивался с такой или похожей проблемой ?

[Геройчиковый]

Добрый вечер!
Вы бы хотя бы написал какая База у вас и какая версия эновии...
А по поводу блокировок: сталкивались недавно у текущего заказчика... у него MS SQL. Но там всё гораздо сложнее было.
По идее, раз транзакции не используете и насильно сами ничего не блокируете - значит не должно у вас ничего подвисать. Количество присоединённых объетов как бы роли тоже не играет.

[ybk]

Да, про версию забыл...эта проблема тянется уже давно с разными версиями.

Сейчас использую ENOVIA R2013x на базе Oracle 11g.
Ошибка связана непосредственно с Oracle, в Matrix получаю стандартное сообщение Oracle о блокировке таблиц.
Опишите, пожалуйста, немного вашу проблему и решение, возможно получится провести какие-то аналогии и поискать решение.

[Геройчиковый]

Добрый день!

У нас была проблема непосредственно с MS SQL.
Сообщение рода:
Message:State 40001: [Microsoft][SQL Native Client][SQL
Server]Transaction (Process ID XXX) was deadlocked on lock
resources with another process and has been chosen as the
deadlock victim. Rerun the transaction. Severity:3
Но это описно в документации как исправить.
В оракл такого не наблюдается, ибо там определённые настройки именно СКЛной базы нужны были.
Вам я бы посоветовал вот это вот почитать в документации:
About the Oracle Parameter File

Configuring for Concurrent Users
Adjustments should be made to the number of processes, open cursors, and dml locks based on the number of concurrent users. Use these formulas as a guide for configuring:
processes= should be 5 times the number of concurrent users.
open_cursors sets the number of open cursors per process. 200 is suggested, but may be scaled up as necessary.
dml_locks = should be 10 times the number of concurrent users.
The number of threads in the Live Collaboration Server should be included in the "concurrent user" count for all settings.
Note: Increasing the number of processes may require more semaphores to be created on some UNIX servers. Refer to the Oracle installation guides for system configuration requirements.

[ybk]

Добрый день!

Спасибо за идею, поизучал Oracle в этом направлении, поигрался с параметрами.
К сожалению, не помогло, симптомы остались те же.
И всё-таки наибольшее число ошибок с Oracle deadlock возникает при попытке удаления businessobject c приаттаченым cодержимым в виде file.

В DS документации часто натыкался на информацию, как делать надо и как не надо, чтобы не получать блокировок.
Может быть есть какие-то соображения по этому поводу, вроде все идеи из документации попробовал, но очень может быть что что-то упустил.

[Геройчиковый]

Добрый вечер!

К сожалению больше пока нчиего не приходит на ум, но всё это выглядит очень странно.
Не должно быть в обычном случае никаких блокировок, тем более на незагруженной базе (я так понимаю, там небось единственная активность - это ваши удаления).
Что-то значит в корне не верно. Если есть возможность - снесите всё абсолютно и поставьте с нуля Оракл, сделайте базу, как рекомендовано в документации с параметрами по умолчанию и т.п. И там пытайтесь потом удалять всякие объекты.
Как предположение: может у вас какие-то несовместимые версии чего-то - Оракл/Джава/Томкэт/Эновия? Сверьтесь с официально поддерживаемыми версиями. У нас у одного консультанта была как-то загвоздка, он её пару недель решал, а как в итоге оказалось, он установил Оракл 10г Р2, когда именно этот Р2 официально не поддерживался.... а просто 10г поддерживался. Но никто не обратил на это внимание. Вот такие вот курьёзы бывают.
И выполняйте периодически такие команды: validate index (или lxidex, как-то так) и - tidy vault
Повышает производительность + вроде как в старых релизах уменшала вероятность блокировок.
Успехов!

[Геройчиковый]

Если ещё актуально, нашёл вот такую вот статью:



Scenario: A large volume data environment operating with a level of code earlier than V6R2012X and using Oracle database may suddenly "freeze". This means all transactions and all activity suddenly stop and no one can do anything. Investigation reveals that the database has "deadlocks", meaning that different transactions are all trying to use the same data inside the database and are blocking each other.

The Cause: Some levels of Oracle have issues where they require all child tables in a foreign key relationship to have indexes on the foreign key column. Without this foreign key index, Oracle chooses bad explain paths and cannot efficiently process the transactions. Updates into such tables are greatly slowed down, and then other transactions get blocked waiting for the very slow updates to finish.


The Solution:

A. One solution is to merely put indexes on all the foreign key columns. However, there is another Oracle issue that we have seen where some of these indexes will also confuse the optimizer and cause unexpected severe degradation of performance in other areas of the functionality. This unexpected degradation may be corrected in Oracle 11g but we have not tested it. This is why the indexes are not provided by DS by default.

B. DS has made some changes in our code to workaround this limitation in Oracle. In V6R2012X we reduce the number of changes to the vulnerable tables, reducing the likelihood this will happen.

C. For code levels pre-12X, the first thing to try is adding only the following single index, and see if this corrects the problem:

--> logging into sqlplus as an oracle dba user
-->replacing "owner" with the correct table schema owner name
-->replace TBSP with the correct tablespace name you are using in your environment
-->replace DEFAULT buffer pool if you want to use a different b.p.

create index OWNER.MXPROPERTY_MXREF_INDEX on OWNER.MXPROPERTY(mxref) pctfree 10 initrans 2 maxtrans 255 storage(initial 500000 next 500000 minextents 1 maxextents 900 pctincrease 50 freelists 1 freelist groups 1 buffer_pool DEFAULT) tablespace TBSP NOLOGGING;
analyze table OWNER.MXPROPERTY compute statistics;
analyze index OWNER.MXPROPERTY_MXREF_INDEX compute statistics;

It is very likely that this index will resolve the deadlocking problem.

D. Some other indexes to consider are indexes on:

mxPolicy(mxDefFormat)
mxPolicy(mxStore)
mxSigReq(mxUsr)

E. If these indexes don't solve the problem, the next step is to index all the foreign key columns. This can be done with a single command inside MQL:

MQL> set system constraint index;

The other steps should be done first before resorting to this one.