обновили Oracle 10.2 до 11.1.0.7.0 словили deadlock

Сегодня обновили Oracle 10.2 до 11,1,0,7,0.

Хочу рассказать на какие грабли наступили:
словили большую массу deadlock-ов, как оказалось, что child таблички которые не имели индексов на столбцах форинкеях на парент таблицы начали вызывать deadlock в момент update парент таблицы nowait. Пришлось пробежаться и создать индексы. Как оно раньше в 10-ке работало - хрен его знает?
Подскажите, что за беда?

Скорее всего планы измелились (в других курсорах). Это привело к задержкам и как следствие возник дедлок.

mayton

Это привело к задержкам и как следствие возник дедлок.

????? Можно с этого места поподробнее?

andrey_anonymous

mayton Это привело к задержкам и как следствие возник дедлок. ????? Можно с этого места поподробнее?

дедлок - это просто стечение обстоятельств, которое в нормально-работающей системе себя не проявляет. Но если у вас есть своя версия просиходящего - то прошу её высказать.

mayton

дедлок - это просто стечение обстоятельств

Нет, уважаемый, дедлок - это очень конкретное стечение обстоятельств.
И возникает это явление, когда несколько параллельных транзакций начинают блокировать один и тот же набор ресурсов в разном порядке.
Как именно это получилось у автора - сложно сказать, не видя системы и планов с десятки и с 11.
Вариантов тут довольно много.
...2автор: дедлок, кстати, бывает не только на строках/таблицах. Неорганизованная конкуренция за слоты ITL тоже может вызвать это явление.
У Вас на чем именно дедлоки-то возникают? (в трассе, которая по этому поводу выпадает из серверного процесса, обычно наглядно видно что к чему)

mayton

дедлок - это просто стечение обстоятельств, которое в нормально-работающей системе себя не проявляет. Но если у вас есть своя версия просиходящего - то прошу её высказать.

Well, стечение обстоятельств which is reproduced by creating/dropping index on FK becomes обстоятельством software vendor could be (directly or indirectly) responsible for. It could be locking mechanist in new release changed like in this example.

SY.

update to 11,

Ваще-то, норнальные дейта-моделеры сами форин-ки индексы проставляют. Но, не будем о грустном...
Похожий слуйчай

У нас базу разработчиков на 11 неделю как перевели.

Выплыл ефект>
Удаляем из таблицы несуществующую запись. Важно именно несуществующую, существующая удаляется, аля

delete from my_table where pk_id = -1

Сессия висит,

session_wait показало что ожидается событие, мне, ..., забыл, а поиск на скорую руку ничего не дал.
Короче событие наводящие на мысль проверить таблицу на неиндексированные ФК столбцы.

Таки да один нашелся. После заведения индекса удаление "состоялось" как ожидалось.

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

Для спортивного интереса я попробовал сделать такую же операцию на одной из таких таблиц.

Результат> удаление отрабатывает как и должно > не виснет.

Тут я задумался.
1. До 11 версии (10) проблема не наблюдалась.
2. Почему разное поведение> Удаление из одной таблицы висит, из другой проходит?

andrey_anonymous

...начинают блокировать один и тот же набор ресурсов в разном порядке.

Это общеизвестная теория. Однако автору от этого не легше. Он, судя по всему, порядок блокирования ресурсов не менял.

andrey_anonymous

[quot mayton] У Вас на чем именно дедлоки-то возникают? (в трассе, которая по этому поводу выпадает из серверного процесса, обычно наглядно видно что к чему)

в трассе писался что update таблицы такойто провален и много всего, из чего взяли

resname [0x2EEE]

- переведя это число в 10-чную ситему и сделав

select * from all_objects a where a.object_id = 12014

находилась таблица, в ней просматривали форинкеи и находился такой который не имеет индекса на ключ, после создания индекса этот deadlock (resname [0x2EEE]) проподал, ну и так далее все deadlocky исключили, все заработало.